Pruebas de Sistemas Software

Aprobando Ingeniera
del Software II
http://www.byteando.com/juanignacio
Comparto todos mis apuntes de IS2 de la Universidad
de Alicante a modo de libro electrnico y se lo dedico,
primero, a Davinia por estar siempre ah y apoyarme, y
segundo a todos aquellos estudiantes de ltimos cursos
que estn puteados con estas ltimas asignaturas y que
suman un problema ms en sus vidas.
Juan Ignacio Alberola Colomo
17/05/2010
Aprobando Ingeniera del Software II 2010

Tema 1: Modelos de Proceso

El Proceso Software.
El proceso de desarrollo software implica el paso de una idea a un programa, a un software. El
proceso en si es lo que hay que hacer para conseguir convertir esa idea en el programa y sean
lo ms parecidos posible.
Este proceso tiene una serie de tareas que se pueden organizar de diferente manera, estas
ordenaciones se conocen como modelos de proceso, que son las mejores maneras de
organizar el proceso para satisfacer al cliente.
Se puede decir que el modelo de proceso es una representacin abstracta de un proceso de
desarrollo software.
El ingeniero software es el responsable de elegir el modelo adecuado para desarrollar el
proyecto y tomar las decisiones adecuadas para entregar el proyecto con xito.
Todo proceso de desarrollo software tiene una serie de tareas bsicas e indispensables, estas
tareas son las de especificacin (qu hay que hacer?), diseo e implementacin (Cmo hay
que hacerlo?), validacin (Qu hay que probar? Cmo lo probamos?), y evolucin (cmo
realizo y mantengo los cambios?). Estas tareas bsicas se organizan de manera diferente en los
diferentes modelos de proceso.
Modelos Genricos.
Disponemos de una serie de modelos de proceso genricos que han ido surgiendo uno
despus de otro intentando suplir las carencias unos de otros. Estos modelos genricos son:
-
Modelo en cascada.
Modelo evolutivo.
Modelo basado en componentes.
Modelo en cascada.
Considera las actividades fundamentales del proceso de desarrollo (especificacin, desarrollo,
validacin y evolucin) y los representa como fases separadas del proceso.
Desde cada tarea se puede volver hacia atrs si se encuentran errores o cambian los
requerimientos.

Actividades:
-
Anlisis y definicin de requerimientos: Los servicios, restricciones, y las metas del

sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en
detalle y sirven como una especificacin del sistema.
Diseo del sistema: El proceso de diseo divide los requerimientos en sistemas
software o hardware. Establece una arquitectura completa del sistema. En el diseo se
identifican y describen las abstracciones fundamentales del software y sus relaciones.
Implementacin y pruebas unitarias: En esta etapa el diseo se lleva a cabo como un
conjunto o unidades de programas. Las pruebas unitarias verifican que cada unidad
implementada cumple sus especificaciones.
Integracin y pruebas del sistema: Las unidades se integran se prueban como un
sistema completo para asegurar que se cumplen los requerimientos.
Puesta en marcha y mantenimiento: Es la fase ms larga. El sistema se instala y se
pone en produccin. El mantenimiento implica corregir fallos no detectados y mejorar
la implementacin.
Este modelo se puede usar para sistemas en los que tenemos los requerimientos MUY claros,
estn bien entendidos y son muy estables.
Lo importante de los modelos, a parte de su organizacin es conocer sus ventajas y sus
inconvenientes.
Ventajas:
-
Hace visible el proceso, nos podemos situar a lo largo del proceso y tenemos control
sobre l. Facilita pues la labor del gestor.
Se produce documentacin en cada fase por lo que como hemos dicho es un proceso
que facilita mucho la visibilidad.
Desventajas:
-
El coste de subsanar omisiones o cambios en los requerimientos as como arreglar

errores implica un alto coste debido a que se debe volver atrs en el proceso. Si el
cliente no tiene claro lo que quiere este proceso no ser el adecuado.
Modelo evolutivo.
El desarrollo evolutivo se basa en la idea de desarrollar una implementacin inicial,
exponindola a los comentarios del usuario y refinndola a travs de las diferentes versiones
hasta que se desarrolla un sistema adecuado.
Las actividades de especificacin, desarrollo y validacin se entrelazan en vez de separarse,
con una rpida retroalimentacin entre estas.
Disponemos de dos tipos de modelos evolutivos:

-
Desarrollo explorativo: se trabaja con el cliente para explorar sus requerimientos y

entregar un sistema final. El desarrollo comienza con las partes del sistema que se
comprenden mejor y se van integrando nuevos atributos propuestos por el cliente.
Desarrollo prototipado: Ms orientado a programas pequeos. Se empiezan con
prototipos para las partes no claras y este siempre se ha de desechar. El prototipo
solamente sirve para aclarar los requerimientos con los clientes y una vez claros se
desarrolla una definicin mejorada de los requerimientos para el sistema. Se puede
usar junto a otros modelos.
Este modelo al igual que los otros, posee unas ventajas y unos inconvenientes:
Ventajas:
-
Suele ser ms efectivo que el enfoque en cascada pues satisface las necesidades
inmediatas del cliente.
El desarrollo y la especificacin se puede hacer de forma creciente. Tan pronto como
los clientes entiendan mejor el problema se puede reflejar en el sistema software.
Desventajas:
-
El proceso no es visible. Los administradores tienen que hacer entregas regularas para
medir su progreso y si el sistema se realiza rpidamente puede no ser rentable generar
documentacin.
Puede surgir una estructura deficiente. Los cambios continuos tienden a corromper la
estructura del software haciendo que incorporar cambios sea cada vez una tarea ms
difcil y costosa.
Estos modelos se suelen usar en sistemas pequeos o medianos hacindose los problemas
tpicos de estos modelos ms graves en sistemas grandes y con un tiempo de vida largos. Para
este tipo de sistemas grandes se recomienda un proceso mixto que incorpore las mejores
prcticas de un modelo en cascada y del desarrollo evolutivo. Las partes del sistema bien
comprendidas se pueden especificar y desarrollar usando cascada, las otras no tan claras
como la interfaz de usuario se deben desarrollar usando un enfoque explorativo.

Modelo basado en componentes.
Se aprovecha de la reutilizacin de cdigo de los proyectos SW. Se basa en la reutilizacin de
componentes ya desarrollados o COTS (Commercial Of The Shelf).
Las etapas de especificacin de requerimientos y validacin son comparables a las de otros

procesos pero intermediamente hay una variacin en las tareas a realizar, estas son:
-
Anlisis de componentes: Una vez obtenida la especificacin se buscan los

componentes para implementar tal especificacin. Normalmente no existe una
concordancia al 100% y los componentes solo proporcionan parte de la funcionalidad
deseada.
Modificacin de requerimientos: Durante esta etapa se ve si se pueden modificar los
requerimientos para que se amolden a los componentes encontrados. Si no podemos
modificar los requerimientos se puede volver a realizar el anlisis de componentes
para buscar soluciones alternativas.
Diseo del sistema con reutilizacin: Se disea o se reutiliza un marco de trabajo para
el sistema. Los diseadores tienen en cuenta los componentes y organizan el marco de
trabajo de acuerdo a satisfacerlos. Si no hemos encontrado componentes
posiblemente tendremos que implementar desde cero algunos mdulos o cambiar
componentes si tenemos acceso a su cdigo.
Diseo e integracin: El software que no se puede conseguir se desarrolla y los
componentes se integran en un nico sistema.
De nuevo, ventajas e inconvenientes.

Ventajas:
-
Reduce la cantidad de software a desarrollar, reduciendo costes y riesgos.

Permite entregar antes el software.
Desventajas:
-
Los compromisos con los requerimientos son inevitables y esto puede dar lugar a que
el sistema no cumpla las necesidades reales de los usuarios.
Si las nuevas versiones de los componentes no estn bajo el control de la organizacin
se pierde el control sobre la evolucin del sistema.

Modelos Iterativos.
Surgen para afrontar los cambios continuos que sufren los requerimientos de un software a lo
largo de su desarrollo. Permitiendo las iteraciones del proceso modificar el trabajo de
iteraciones anteriores.
La esencia es que el desarrollo se produce en conjuncin con la especificacin, viene a ser lo
mismo que se ha dicho en el prrafo anterior.
Las iteraciones suelen ser de duracin fija (entre 2 y 6 semanas) y para ellas se eligen un
conjunto reducido de casos de uso o requerimientos a implementar. Durante ese tiempo
solamente se afronta la implementacin de esos casos de uso. Se dice entonces que son timeboxed. Si elegimos x casos de uso y vemos que no da tiempo a implementarlos en el tiempo
estipulado no se retrasa o alarga la iteracin sino que se elimina trabajo y se deja para la
siguiente.
Despus de ese desarrollo se obtiene un sistema ejecutable, pero an incompleto, es
importante destacar que este sistema no es desechable, sino que ya es una parte del sistema
final.
Dentro de los modelos iterativos nosotros vamos a estudiar un par:
-
Modelo incremental.
Modelo en espiral.
Modelo incremental.
Los clientes identifican, a grandes rasgos, los servicios que proporcionara el sistema y se
identifican los ms importantes y los menos. Despus de esto se definen varios incrementos
en donde cada uno proporciona un conjunto de la funcionalidad del sistema.
La asignacin de las funcionalidades a los incrementos depende de la prioridad, as
normalmente los primeros incrementos tienen las funcionalidades ms crticas.
En los incrementos, cuando se decide lo que se va a implementar se congelan los
requerimientos y no se pueden modificar. Adems, cuando se acaba un incremento se le
puede proporcionar al cliente para que lo pruebe.

Ventajas:
-
Los clientes no tienen que esperar hasta que el sistema est completo para sacarle
provecho. El primero incremento satisface los requerimientos ms crticos de tal forma
que se puede usar el software inmediatamente.
Los clientes pueden usar los incrementos iniciales como prototipos y obtener
experiencia sobre los requerimientos posteriores del sistema.
Normalmente no suele fracasar el proyecto, pero se pueden encontrar problemas en
algunos incrementos.
Dado que lo ms crtico se entrega antes y los incrementos posteriores se integran en
ellos, hace que lo ms crtico se pruebe ms. As se hace menos probable encontrar
errores en parte crticas del sistema.
Desventajas:
-
Los incrementos deben ser pequeos y se debe entregar alguna funcionalidad del
sistema. Puede ser difcil adaptar el tamao a la funcionalidad.
Puede necesitarse algn recurso en todos los incrementos, pero como se implementa
de manera incremental no nos daremos cuenta hasta que sea necesario.
Modelo en espiral.
Este modelo tambin es iterativo. Cada ciclo de la espiral representa una fase del proceso
software, de esta forma el ciclo ms interno podra referirse a la viabilidad del proyecto, el
siguiente a la definicin de requerimientos, etc, aunque no hay fases fijas dando las vueltas
necesarias dependiendo de lo que sea necesario.
La principal caracterstica de este modelo es que los riesgos se resuelven de forma explcita
en cada vuelta de la espiral.
Lo podemos usar como el modelo en cascada, pero con la diferencia de que se explicitan los
riesgos, por lo que las vueltas hacia atrs no van a suceder tanto como en cascada.

Cada ciclo, como se puede ver, se divide en cuatro secciones, en orden:
-
Determinar objetivos, alternativas y restricciones: Se definen los objetivos especficos

y se identifican las restricciones del proceso y del producto trazando un plan detallado
de gestin. Adems se identifican los riesgos y a partir de estos se planean estrategias
alternativas.
Evaluacin y reduccin de riesgos: Se analizan los riesgos identificados y se defienen
los pasos para reducir tales riesgos.
Desarrollo y Validacin: Se desarrolla el sistema despus de reducir los riesgos.
Planificar siguiente fase: Si hemos acabado una fase, en esta seccin se determina
pasar a una nueva fase o bien seguir en la misma con otro ciclo de la espiral.
Modelos giles.
Este tipo de modelos surgen para subsanar los problemas de todos los anteriores,
normalmente altos costes. Estos modelos:
-
Se centran en el cdigo en vez de en el diseo.

Se basan en aproximaciones iterativas del desarrollo del software.
Pretenden entregar software funcional rpidamente y evolucionar este tambin de
forma rpida para satisfacer los requerimientos cambiantes.
Usados normalmente para sistemas de empresas pequeas o medianas.

Los principios bsicos de todos los modelos giles son los siguientes:

Programacin Extrema XP.
Posiblemente el mtodo gil ms ampliamente utilizado. Se basa en el desarrollo iterativo de
pequeos incrementos de funcionalidades.
Sus aspectos bsicos son:
-
Desarrollo incremental: Llevado a cabo mediante entregas pequeas del sistema

adems de frecuentes con unas pocas funcionalidades.
Implicacin del cliente: El cliente forma parte del equipo de desarrollo trabajando
codo a codo con este. Son los responsables de establecer las pruebas de aceptacin
del sistema.
Centrado en la gente, no en el proceso: Se programa por parejas, el cdigo es de
propiedad colectiva y se desarrolla en jornadas de trabajo no excesivas.
Centrado en los cambios: Se hacen entregas regulares del sistema, con un desarrollo
probado y una integracin continua.
Programacin por parejas: Se trabaja en parejas, verificando cada uno el trabajo del
otro para que no se escapen errores.
Sentido colectivo: Las parejas trabajan en todas las reas del sistema, as todos los
desarrolladores conocen todo el sistema sin crearse lagunas de conocimiento.
Pruebas e integraciones continas: Cuando se acaba una tarea se integra en el
sistema.
Diseo simple: Diseo necesario solo para cumplir los requerimientos de unidad.
Ritmo sostenible: Nada de horas extra, ya que se suele reducir la calidad del cdigo y
baja la productividad a medio plazo.
Refactorizacin y mejora del cdigo: Cuando se encuentran mejoras en el cdigo, se
introducen inmediatamente.
Los ciclos XP suelen ser cortos (1-3 semanas por iteracin). Y cada 2 o 3 semanas se hace un
plan para la iteracin siguiente sin mucho detalle inicialmente para posteriormente ir
desglosndolo. Normalmente se parte de escenarios (stories) que se dividen en tareas que se
planifican. Despus se desarrolla, integra y se prueba para hacer una release y evaluar el
software. Luego, se vuelve a empezar con otros escenarios.
10

Modelo RUP.
Es un modelo relativamente moderno derivado del trabajo con UML. Es un modelo hibrido
que integra caractersticas de cascada, iteraciones y gil.
Normalmente se definen tres perspectivas:
-
Dinmica: Muestra las fases a lo largo del tiempo.

Esttica: Actividades que se llevan a cabo durante todas las fases.
Prctica: Sugiere buenas prcticas.
Perspectiva dinmica. Fases.

-
11
Inicio: Se establece un caso de negocio del sistema. Se identifican todas las actividades
externas, tanto personas como sistemas que interactuaran con el sistema y se definen
estas interacciones. Esa informacin se usa para evaluar la aportacin que hace el
sistema al negocio y si es de poca importancia se puede cancelar el proceso en esta
fase.
Elaboracin: Se desarrolla una compresin del dominio del problema, se establece un
marco de trabajo arquitectnico y un plan del proyecto que identifica los riesgos clave.
Al finalizar se tiene un modelo de los requerimientos, una descripcin arquitectnica y
un plan de desarrollo.
Construccin: Se disea el sistema, se programa y se hacen pruebas. Se tiene el SW
operativo y la documentacin.
Transicin: Se pone el sistema en produccin, generando instalaciones, distribuyendo
el sistema, etc.

Perspectiva esttica. Actividades o flujos de trabajo:
-
Modelado del sistema: Se modelan los procesos de negocio usando los casos de uso
del negocio.
Requerimientos: Se definen los requerimientos funcionales y no funcionales haciendo
casos de uso para los primeros.
Anlisis y Diseo: Se crea y documenta un modelo de diseo usando modelos
arquitectnicos, modelos de componentes, de objetos y de secuencia.
Implementacin: Se implementan los subsistemas como componentes.
Pruebas: Se llevan a cabo junto con la implementacin.
Despliegue: Release del producto y puesta en produccin.
Gestin de configuraciones: Gestin de los cambios en el sistema.
Gestin del proyecto: Gestin del desarrollo del sistema.
Entorno: Identificar las herramientas que se van a usar.
Perspectiva prctica:
-
Desarrollo iterativo: Planificar incrementos con la prioridad de los mismos para el

cliente
Gestin de requerimientos: Documentacin explcita de los mismos al mismo tiempo
que estar al tanto de los posibles cambios.
Modelado visual del software: UML para presentar vistas estticas del sistema.
Verificacin de calidad: Asegurarse que cumple estndares de calidad.
Control de cambios: Usar un sistema de gestin de cambios y procedimientos para
gestionarlos.
Se vers mas de RUP en el material adicional y en las prcticas del tema.
12

Tema 2: Gestin de Proyectos
13

En este tema se estudia el tema de la gestin de proyectos, es una actividad que se lleva a
cabo durante todo el proceso de desarrollo y se puede considerar una actividad paraguas ya
que lo envuelve desde principio a fin. Un ejemplo de esto lo tenemos en RUP como disciplina
de soporte llevada a cabo en cada una de las fases e iteraciones.
Es importante conocer a qu se dedica el gestor de proyectos, por eso se empieza estudiando
las actividades de gestin entre las que est la creacin de una agenda para el proyecto y su
control y monitorizacin. Estos tres puntos son los esenciales en el tema.
Actividades de de gestin.
El gestor de proyectos se encarga de varios asuntos, entre ellos elabora un plan de proyecto
que contempla la creacin de una agenda, adems hace estimaciones de coste y tiempo, se
evalan los riesgos y se organiza al personal.
Tambin monitoriza y controla el plan del proyecto, identificando los hitos y entregas del
proyecto adems el gestor debe tener conocimiento del progreso del proyecto y comparar el
progreso con lo que se haba planificado.
Selecciona al personal basndose en sus conocimientos y su disponibilidad. En un entorno
ideal todos sabran de todo y estaran disponibles al 100% con la experiencia necesaria, pero
normalmente se elige un equipo profesional mnimo capaz de desarrollar el trabajo basndose
en sus conocimientos y en su personalidad.
Por ltimo, el gestor debe rendir cuentas, creando y presentando informes. Debe informar a
los clientes y contratistas sobre el proyecto, en consecuencia, la habilidad de comunicarse
tanto por escrito como oralmente es esencial para el gestor. De hecho, es un asunto que
Galipienso busca en los objetivos de la asignatura, la capacidad de comunicarnos y escribir
bien.
El OBJETIVO FINAL es entregar el proyecto a tiempo, sin exceder el coste estimado y
satisfaciendo las necesidades del cliente.
Volviendo al plan del proyecto, en la planificacin se decide de antemano QUE hay que hacer,
COMO hay que hacerlo, CUANDO hay que hacerlo y QUIEN lo va a hacer. Esto es importante
pues en el examen no hay porque enrollarse, simplemente si se pide un plan de proyecto
debemos contestar a estas cuestiones de forma resumida.
La buena gestin del proyecto depende de planificar completamente el progreso del proyecto.
El gestor se anticipa a los problemas que pueden surgir y prepara soluciones a estos
problemas. Un plan preparado al inicio de un proyecto debe usarse como conductor para el
proyecto y debe ser el mejor posible de acuerdo con la informacin disponible. El plan
evolucionar conforme el proyecto avance y se disponga de ms informacin.
Para planificar un proyecto existen diversos algoritmos, pero en la asignatura nos ponen uno
que es el siguiente, se adjunta la imagen de las transparencias y a continuacin se explica cada
apartado.
14
Las actividades en azul son actividades de creacin del plan y las que estn en rojo son
actividades de monitorizacin. Los dos siguientes apartados se van a centrar exclusivamente
en confeccionar la agenda y en monitorizar el progreso del proyecto.
Pero ahora veamos cada actividad de la planificacin.
Establecer objetivos, mbito y restricciones del proyecto: Se decide que es lo que se quiere
hacer, los lmites del proyecto y su dominio as como los requisitos funcionales y no
funcionales, de tiempo, coste, personal y maquinaria disponible.
Definir hitos y entregas: Servir para monitorizar el proyecto y darle visibilidad.
Estimar recursos: Vemos cuanta gente vamos a necesitar en funcin del tamao y complejidad
del proyecto.
Organizar al grupo de trabajo: Asignar trabajo al personal y decidir cundo lo va a hacer.
Determinar estndares de calidad: Poner en comn prcticas entre el equipo para que el
proyecto sea lo ms uniforme posible.
Determinar riesgos: Pensar en los problemas que pueden surgir y anticipar soluciones.
Organizar comunicacin del grupo: Dependiendo de cmo se comunique el equipo el proyecto
avanzar ms rpidamente o no.
Confeccionar una agenda: Identificar las tareas y sus dependencias.
Definir presupuesto:
Escribir plan: Contestar a QUE, COMO, QUIEN y CUANDO.
Este ltimo plan puede tener diferentes formatos, pero el que nos dan en las transparencias es
el siguiente.
I O A R D A M.
15

Introduccin: Describe brevemente los objetivos del proyecto y expone las restricciones que
afectan a la gestin del mismo.
Organizacin del proyecto: Describe la forma en la que el equipo de desarrollo est
organizado, la gente involucrada y sus roles en el equipo. Modelo de proceso con sus
actividades y orden.
Anlisis de riesgos: Describe los posibles riesgos del proyecto, la probabilidad de que surjan
estos riesgos y las estrategias de reduccin de riesgos propuestos.
Requerimientos hardware y software: Describe el hardware y el software de ayuda necesario
para llevar a cabo el desarrollo adems si es necesario comprar hardware o software se incluye
su coste.
Descomposicin del trabajo (WBS): Describe la divisin del proyecto en actividades e
identifica los hitos y las entregas.
Agenda del proyecto: Describe las dependencias entre actividades, el tiempo estimado
requerido para alcanzar cada hito y la asignacin de gente a esas actividades.
Mecanismos de monitorizacin e informes: Cundo se deben generar informes asi como los
mecanismos de supervisin a usar.
Confeccin de agendas.
El siguiente proceso de confeccin de agendas sirve como hilo conductor para lo que resta de
tema.
Los gestores estiman el tiempo y los recursos requeridos para completar las actividades y
organizarlas en una sucesin coherente. A menos que el proyecto a calendarizar sea similar a
otro anterior las estimaciones previas son una base no cierta para este proceso.
Los calendarios se deben actualizar conforme se vaya obteniendo nueva informacin.
Las primeras actividades del proceso de creacin de agendas (identificar actividades y
dependencias entre actividades) no nos resultan nuevas pues es lo que se estudi en el primer
16

tema y viene influenciado por el modelo de proceso a seguir. Las salidas o representaciones de
la agenda pueden ser varias, los diagramas de actividades muestran las dependencias entre
ellas y los diagramas de barras el tiempo que llevan dichas actividades.
Si nos centramos en la identificacin de actividades vemos que la entrada son los requisitos
software y la salida es un WBS o Work Breakdown Structure.
Un WBS identifica las actividades del proyecto y las estructura por niveles de abstraccin de
forma jerrquica. Los WBS nos ofrecen una vista de todo el trabajo significativo, una
descomposicin clara en tareas para la asignacin de responsabilidades y un marco para la
confeccin de la agenda y la estimacin y monitorizacin de costes.
Hay que tener en cuenta que NO es un WBS, no es un plan del proyecto ni una agenda, ni una
cronologa de realizacin de actividades.
Al identificar las actividades tambin se deben identificar los hitos y las entregas.
Las actividades deben organizarse para producir salidas tangibles para dar visibilidad al
proyecto y ver el progreso del mismo para favorecer la gestin. Como el software es intangible
la informacin solo se puede proveer como documentos que describen el estado del software.
Los hitos o milestones son instantes de tiempo que marcan el final de alguna actividad del
proceso de desarrollo SW. En cada uno debe existir una salida formal, como un informe que se
deba presentar al gestor y no demasiado amplios. Los hitos implican una monitorizacin y
control del trabajo realizado.
Las entregas son resultados del proyecto que se entregan a los clientes.
La parte importante est en saber cunta visibilidad dar al proyecto y definir la cantidad de
hitos para que el proyecto sea exitoso.
Despus de identificar las actividades hay que ver si existen dependencias entre ellas e
identificarlas.
Necesitamos saber por ejemplo si una actividad debe haber finalizado por completo antes de
que otra pueda empezar, o puede que una actividad no pueda empezar despus de un cierto
tiempo despus de que acabe otra (lag) o tambin puede que estemos condicionados por otro
tipo de restricciones como que una actividad deba acabar o empezar lo antes posible.
En MS Project tenemos varias dependencias entre tareas.
FC o Finalizar para Comenzar: Una tarea no empieza hasta que otra acabe.
CC o Comenzar para Comenzar: Empiezan a la vez.
FF o Finalizar para Finalizar: Finalizan a la vez.
CF o Comenzar para Finalizar: Una tarea no acaba hasta que empieza otra.
Adems de las dependencias tenemos otras restricciones sobre las fechas o delimitaciones.
17

Sin fecha: Empezar lo ms pronto posible o lo ms tarde posible.
Semiflexibles: No empezar antes de X.
Inflexibles: Empezar en X.
Volviendo al proceso de creacin de agendas, lo que sigue es la estimacin de recursos y la
asignacin de estos a las tareas.
Los recursos pueden ser de varios tipos, por ejemplo, de trabajo refirindose a gente y
equipamiento, de materiales o de coste. Una tarea adems puede requerir ms de un recurso.
Estos recursos no pueden estar disponibles el 100% de su tiempo, sobre todo los de trabajo
(gente) as que la asignacin de recursos a las tareas se har en base a la disponibilidad de
estos
Para asignar los recursos primero se estiman los recursos necesarios para cada tarea en base al
ESFUERZO requerido para finalizar dicha tarea y luego se asignan los recursos a cada actividad.
El esfuerzo de una tarea es el tiempo necesario para acabarla, no hay que confundirlo con la
duracin pues esta depender de los recursos asignados.
La duracin normalmente se mide en das y el esfuerzo en horas.
Adems cada recurso asignado a tareas tiene una disponibilidad D al da, por ejemplo, 8 horas.
Esfuerzo, duracin y recursos no se pueden contemplar de manera independiente, estn
interrelacionados entre ellos de la manera siguiente, segn las herramientas automticas de
gestin de proyectos.
Esfuerzo = duracin * disponibilidad al da.
Realmente esta relacin es exponencial, como ya se ver, pero los programas automticos
solamente hacen clculos y usan esta frmula. Estas herramientas no hacen estimaciones, solo
clculos.
En MS Project, basndonos en la anterior ecuacin, si dejamos alguno de los campos fijos se
recalculan los dems en base a la siguiente tabla.
Si estamos con la duracin fija y la actividad es condicionada por el esfuerzo, la asignacin de

ms recursos reduce los valores de la unidad individual de cada recurso. O sea, que si
metemos ms recursos, estar cada uno menos disponible.
18

Si la tarea nicamente est condicionada por el esfuerzo modifica la duracin si se aaden o
quitan recursos. El trabajo o esfuerzo permanece constante
Una vez que tenemos todas las entradas en el programa (actividades, relaciones, duraciones y
recursos) se hacen unos CALCULOS.
Fechas de inicio y fin ms tempranas y tardas de las actividades.
Holguras totales y libres de las actividades.
Una holgura total es el tiempo que una actividad puede retrasarse sin retrasar el proyecto
entero. Una holgura libre es el tiempo que una actividad puede retrasarse sin retrasar las
actividades dependientes de ella.
El camino crtico es aquel formado por actividades con holgura total igual a cero. Y es
importante saber que puede haber ms de un camino crtico.
Con esto podemos ir monitorizando la agenda adelantando o retrasando tareas segn sea
necesario respondiendo ante problemas que se vayan presentando a lo largo del desarrollo.
Monitorizacin y control.
Una vez realizada la agenda, hay que ir controlndola y tomando decisiones con el objetivo
principal de entregar el proyecto a tiempo con los costes apropiados.
El 70% de los proyectos cuestan ms de lo presupuestado o se entregan ms tarde de lo
planificado y el 52% de ellos se entregan con un 189% de lo presupuestado.
Otros muchos ni se entregan.
Monitorizar o hacer un seguimiento a una agenda consiste en comprobar si la agenda
planificada se ajusta con la agenda real. A la agenda inicial la llamaremos agenda planificada,
es la que hemos creado siguiendo los pasos del apartado anterior basada en nuestra intencin
inicial y estimaciones. La agenda real es lo que realmente est sucediendo con el proyecto a
partir de informacin real.
Para hacer la monitorizacin se necesitan datos que ofrezcan una visin cuantitativa de la
agenda, estos datos son mtricas del proyecto. Se pueden usar varias de ellas, por ejemplo, la
holgura libre dice lo que se puede retrasar una tarea sin afectar a las dems.
En MS Project para hacer el seguimiento de una agenda hay que seguir el siguiente
procedimiento.
-
19
Guardar lnea base del proyecto: Esto se hace a travs de la opcin Proyectos
Herramientas Establecer lnea base. Los campos duracin, trabajo, comienzo, fin y
costo se guardan como valores PREVISTOS.
Establecer fecha de estado: Definimos en qu fecha nos encontramos a travs de las
opciones Proyecto Informacin del proyecto Fecha de estado.

-
Introducir datos reales: HerramientasSeguimientoActualizar tareas. Con esto los

valores que estaban previstos pasan a ser REALES.
Comparar el progreso: A travs de una vista Gantt de seguimiento.
Entre las mtricas anteriormente nombradas existen varias ms como por ejemplo:
-
Fechas de inicio y fin.

Duraciones.
Holguras.
Anlisis del Valor Acumulado (EVA)
Pero la cuestin importante es el USO de estas mtricas para controlar y monitorizar una
agenda.
Controlar una agenda consiste en tomar las decisiones adecuadas para que las diferencias
entre las agendas planificada y real sean mnimas partiendo de que las actividades crticas (con
holgura total igual a cero) no se pueden retrasar y que las actividades no crticas se pueden
retrasar siempre y cuando el retraso no supere su holgura total.
Earned Value Analysis (EVA).
El Valor Acumulado es una mtrica, tal y como se vio en el apartado de mtricas. Esta mtrica
en concreto proporciona una informacin cuantitativa del progreso de un proyecto asignando
a cada tarea un valor devengado basado en su porcentaje estimado del valor total.
EVA permite vislumbrar dificultades antes de que estas sucedan lo que permite tomar
decisiones antes que el proyecto entre en crisis y la liemos parda.
Un EVA siempre se realiza en un momento determinado del tiempo y bsicamente usa y
compara tres tipos de informacin:
-
Cunto trabajo (del planificado) debera haberse realizado hasta el momento? BCWS.
Cunto se ha gastado hasta el momento? ACWP.
Cul es el valor (en trminos de lnea base) del trabajo realizado hasta el momento?
BCWP.
Un ejemplo de estos tres parmetros se puede encontrar en las transparencias 42, 43 y 44

seguidas en clase.
Otro parmetro es el BAC o trabajo planificado al final del proyecto.
-
Si BAC = BCWS: La tarea debera haber acabado ya.

Si BAC > BCWS: La tarea aun no ha acabado. Para ver el porcentaje hecho de la tarea
se divide BCWS/BAC.
Veamos ahora el funcionamiento de EVA.

Indicadores de PROGRESO.
-
20
Schedule Variance (SV) = BCWP BCWS.

-
Schedule Performance Index (SPI) = BCWP / BCWS.

Si BCWP > BCWS la tarea o proyecto va adelantada segn la agenda planificada.
Un SPI de 1.5 significa que slo se ha usado un 67% del tiempo planeado para
completar una parte de la tarea en un determinado periodo de tiempo. Para saber el
porcentaje se hace el SPI al revs, o sea, BCWS / BCWP.
Indicadores de PRODUCTIVIDAD.
-
21
Cost Variance (CV) = BCWP ACWP.

Cost Performance Index (CPI) = BCWP/ACWP.
Si BCWP > ACWP la tarea o proyecto est gastando menos de lo planificado.
Un CPI de 0.8 significa que se est gastando un 25% ms de lo que estaba planificado
(por cada planificado se est gastado 1.25) para saber esto hay que hacer el CPI
pero al revs ACWP / BCWP.

Tema 2: Gestin de proyectos - Ejercicios
22

Qu modelo de proceso representa la siguiente agenda?
Representa un modelo en cascada, se pueden ver fcilmente las distintas actividades del
proceso de desarrollo (Requerimientos, Anlisis y Diseo, Implementacin, Pruebas y
Despliegue). Por otro lado se puede considerar que tiene tintes de un desarrollo evolutivo ya
que se presenta un prototipo intercalndolo con los requerimientos.
Qu estilo de plan elegiras como gestor de proyecto?
El segundo, ya que indica claramente la salida de cada tarea, el primero servira en todo caso
para alguna plantilla genrica.
Recalcular los valores para la siguiente tarea con las unidades (recursos) fijos.
Vamos a seguir la ecuacin para recalcular que usa MSProject que es Trabajo = Duracin x
Unidades.
De esta manera.
Si duracin se cambia a 2 das el trabajo se recalcula y 2*8 = 16. El trabajo cambia a 16.
23

Si el trabajo se cambia a 32 horas entonces la duracin se recalcula 4*8 = 32. La duracin es
de 4 das.
Si las unidades se reducen a la mitad la duracin aumenta proporcionalmente, si eran 3 das
ahora es el doble al reducir las unidades a la mitad. La duracin es de 6 das.
Recalcular los valores para la siguiente tarea con la duracin fija.
Igual que en el ejercicio anterior pero dejando la duracin fija.

Si se cambia la duracin a 2 dias se recalcula el trabajo a 16 horas.
Si se cambia el trabajo a 32 horas Lucas estar sobreasignado ya que al ser la duracin fija
necesitara trabajar 10.6 horas al da para completar la tarea en 3 das.
Si las unidades se reducen a la mitad el trabajo se recalcula a la mitad. Ahora es de 12 horas.
Ejercicios sobre holguras.
Qu pasa si A se retrasa 3 das? No pasa nada, el proyecto no se retrasa y B puede comenzar

lo antes posible.
Qu pasa si A se retrasa 4 das? El proyecto no se retrasa pero la holgura total de A se reduce
en 4 y pasara a ser 2, por otro lado la holgura total de B pasara a ser 2.
Qu pasa se A se retrasa 6 das? El proyecto no se retrasa pero las dos actividades se
convierten en crticas al consumirse en ambas toda su holgura total.
24

Realizar un anlisis cuantitativo del progreso de las siguientes tareas.
Con MSExcel he resuelto la tabla que hay que analizar siguiendo las frmulas adecuadas.
SV = BCWP BCWS.
SPI = BCWP / BCWS.
CV = BCWP ACWP.
CPI = BCWP / ACWP.
BAC
1000
1500
6000
1000
1000
2000
BCWS
1000
1500
5000
500
500
1000
BCWP
1000
1000
4000
0
500
1500
ACWP
1200
1500
4500
0
750
1500
SV
0
-500
-1000
-500
0
500
CV
-200
-500
-500
0
-250
0
SPI
1
0,66666667
0,8
0
1
1,5
CPI
0,83333333
0,66666667
0,88888889
0,66666667
1
Tarea 1.
La tarea debera haber acabado segn lo planificado pues BAC = BCWS. Por otro lado la tarea
se est ejecutando segn la agenda ya que SV=0. Vemos tambin que la tarea ha acabado
porque BAC = BCWS = BCWP.
Por otro lado hemos gastado ms de lo presupuestado, concretamente 20% ms, esto quiere
decir que por cada presupuestado estamos gastando 1.20.
Tarea 2.
La tarea debera haber terminado segn lo planificado pues BAC = BCWS. Por otro lado la tarea
va con retraso porque SV = -500, se ha completado un 66% de la tarea.
Estamos gastando ms de lo presupuestado, concretamente 1.5 por cada presupuestado.
Tarea 3.
25

La tarea aun no ha acabado segn lo planificado, de hecho llevara el 83% segn lo planificado.
Va retrasada porque SV < 0, concretamente lleva un 80%.
Por otro lado por cada presupuestado hemos gastado 1.125. As que en un 80% completado
hemos gastado 500 ms.
Tarea 4.
Debera llevar el 50% segn lo planificado, pero no ha empezado.
Tarea 5.
La tarea aun no ha acabado, segn lo planificado lleva el 50%. SV = 0 nos indica que la tarea se
est llevando a cabo segn la agenda pero hemos gastado 250 ms de lo que haba
presupuestado, esto quiere decir que por cada presupuestado hemos gastado 1.5.
Tarea 6.
Segn lo planificado no ha acabado y debera llevar el 50%. La tarea va adelantada en un 50%.
Para completar lo que se lleva de tarea se ha usado un 67% del tiempo estipulado y de
momento se ajusta al presupuesto sin gastos de ms.
26

Tema 3: Estimacin de Proyectos
27

INTRODUCCIN. DEFINICIONES.
Una estimacin es un proceso analtico para predecir el coste y la duracin de un proyecto
que ofrece unas ciertas funcionalidades. Se puede entender el proceso analtico como un
anlisis de unos datos de entrada que producen una salida que en este caso es la prediccin.
Esta prediccin puesto que nadie es adivino es difcil acertar de pleno.
Las estimaciones siempre llevan una probabilidad asociada ya sea explcita o implcita, por
ejemplo si decimos que un proyecto estar acabado en 10 das asumimos con el 100% de
certeza que en 10 das estar acabado, esto no es realista, no se hacen predicciones con un
solo valor. Las predicciones deben entrar en un intervalo razonable, se debe dar un rango de
valores lo suficientemente amplio como para que la probabilidad de que el valor correcto
pertenezca al rango sea lo ms alta posible, si es posible cercana al 100%.
Las estimaciones deben ser lo ms exactas posible aunque normalmente nos quedaremos por
arriba o por abajo lo que tendr sus consecuencias.
Por ejemplo las estimaciones optimistas, es decir, en las que suponemos que acabaremos
antes de lo que en realidad suceder conducen a un fracaso del proyecto y a generar ms
errores debido al estrs de los programadores que a su vez vern su salud minada. Por otro
lado se emplear ms tiempo en reuniones para la reconduccin del proyecto.
Por otro lado las estimaciones pesimistas, es decir, las que asumen que acabaremos ms tarde
de lo que se podra acabar activan la ley de Parkinson que viene a decir que trabajaremos
durante todo el periodo de tiempo, si tenemos 2 meses nos apaaremos para trabajar esos
dos meses, igual que si tuvisemos 40. Adems se sufre el sndrome del estudiante, es decir,
dejar todo para ltima hora porque aun queda tiempo.
Como es muy difcil ser exacto al menos es conveniente saber que puede suceder al
sobreestimar o al subestimar.
Estimacin y planificacin. Importancia de las estimaciones. Errores al estimar.

La estimacin y la planificacin son conceptos relacionados, de hecho veamos como para
hacer una agenda es necesario estimar tiempo y coste.
La planificacin hace referencia a QUE hay que hacer para conseguir un objetivo, la meta es
conseguir un resultado en particular.
Por otro lado la estimacin hace referencia a CUANTO hay que hacer de cada cosa, y la meta
es conseguir la mayor exactitud posible.
Adems las estimaciones tienen mucho que ver con el control del proyecto, es decir, con su
monitorizacin. As pretenden determinar si los objetivos del proyecto son realistas para
permitir un control de forma que se cumplan los objetivos.
Las estimaciones exactas tienen mucha importancia ya que estas:
28

-
Mejoran la visibilidad del estado del proyecto: Si la agenda planificada es realista

(basada en estimaciones exactas) se puede hacer un seguimiento segn los planes.
Favorecen la alta calidad: Al estar lo real ajustado a lo planificado la presin sobre la
agenda es menor por lo que se cometen menos errores.
Mejoran la coordinacin con actividades de no programacin: La agenda debe
incluir actividades que no sean de programacin.
Incrementa la credibilidad del equipo de desarrollo: Al ajustarse lo real a lo
planificado se tendr que variar poco y no tendremos que hacer modificaciones lo que
incrementa la credibilidad. Estos tos son unas mquinas, han acertado a la primera.
Proporcionan informacin de riesgo en etapas tempranas: Al detectar discrepancias
entre los objetivos y las estimaciones indican un riesgo de que el proyecto fracase.
Las estimaciones pueden ser poco exactas debido a que podemos cometer errores al estimar,
estos errores pueden provenir de diferentes lugares.
-
Informacin inexacta: No disponemos de suficiente informacin sobre lo que tenemos

que construir.
Informacin inexacta sobre las capacidades de la organizacin: No sabemos las
habilidades del equipo que se encargar de desarrollar el producto.
Proceso de desarrollo catico: Todo es un caos, desorganizado, poca comunicacin,
etc.
Inexactitud en el proceso de estimacin: Podemos omitir actividades y
requerimientos as como una subjetividad, por ejemplo, al apreciar el tamao del
proyecto.
Cono de la incertidumbre y los valores de las estimaciones.
El cono representa la exactitud en el mejor caso que es posible conseguir en las estimaciones
del software en diferentes momentos del proyecto. El cono no se estrecha por s mismo. Se
estrecha tomando decisiones que reducen las fuentes de variabilidad sobre el proyecto.
29

Para entender esto mejor la x es lo que queremos estimar, por ejemplo esfuerzo, tiempo y
funcionalidades. En el momento de viabilidad del proyecto la mejor estimacin posible ser de
4x o 0.25x, no podremos obtener una mejor estimacin, por eso puede no ser conveniente
usar mtodos sofisticados de estimacin en estas etapas tempranas. Cuando vamos teniendo
partes del proyecto claras es ms fcil estrechar el cono, por ejemplo, despus de tener la
viabilidad, los requerimientos y el diseo se estrecha bastante. En ltima instancia, al final del
cono, con todo desarrollado la estimacin ser la realidad.
En el eje x se tiene el nivel de detalle considerado a la hora de presupuestar, o mejor

expresado, la cantidad de informacin para la estimacin.
Se pueden ver varias grficas superpuestas.
-
30
Budgeting effort: Cuanta ms informacin se disponga ms esfuerzo costar hacer una

estimacin.
Budget maintainability: Cuanta ms informacin se tenga la mantenibilidad de las
estimaciones se ver reducida ya que tendremos ms variables y ms claras.
Budget accuracy: A ms informacin ms exactos seremos.
Budget value: Hay que conseguir un equilibro entre el esfuerzo y la mantenibilidad
para conseguir ms valor.

Qu hay que estimar? Esfuerzo, tiempo y coste total.
Cuando estimamos tenemos que responder a las siguientes preguntas.
-
Cunto esfuerzo es necesario para completar una actividad?

Cunto tiempo se necesita para completar una actividad?
Cul es el coste total de una actividad?
Adems cuando respondemos a estas preguntas podemos estimar la cantidad de

funcionalidades que se pueden entregar.
Como ya se ha dicho antes, las actividades de estimacin y confeccin de agendas son
actividades de gestin que se intercalan.
El esfuerzo requerido para realizar una tarea X es la cantidad de trabajo que se necesita para
completar dicha tarea X. No confundir con la duracin que depender del nmero de recursos
asignados a dicha tarea, de la cantidad de comunicacin requerida y de la capacidad de la
tarea para ser divida en partes.
El esfuerzo es medido en personas/tiempo, normalmente en personas/mes que equivale a
152 horas de trabajo.
Volviendo a la duracin nos podramos encontrar con varios casos, unos ms realistas que
otros. En las grficas hay una relacin de cantidad de personas con los meses necesarios para
completar una tarea.
Grfica
Descripcin
Sera una tarea completamente particionable y asignable a

personas sin necesidad de una comunicacin entre ellas.
Una tarea no particionable, tiene que ser desarrollada como un

todo o disponer de restricciones secuenciales.
31
Es una tarea particionable pero se requiere comunicacin entre las

subtareas.
Es el caso ms realista. La tarea puede particionarse pero se

requiere comunicacin entre las personas. Se puede ver que al
aadir personas a partir de un punto la cantidad de tiempo
necesario crece exponencialmente.
Hablando de coste y precio.

Desarrollar un software tiene un coste asociado normalmente dado por las siguientes
variables.
-
Costes de esfuerzo (horas trabajadas): Engloban los sueldos de los ingenieros y gastos
de seguros o seguridad social.
Costes hardware y software: Se necesitan mquinas? Comprar entorno de
desarrollo?
Costes de viajes y aprendizaje: Congresos, cursos.
Otros: Alquileres, redes, recursos compartidos.
En cuanto al precio, aunque no es objetivo de la asignatura, hay mltiples factores que

influyen en l. Tener en cuenta que el precio es los costes ms los beneficios.
-
32
Oportunidad de mercado: Podra ofrecer un bajo precio debido a que quiere

conseguir cuota de mercado. Obtener pocos beneficios al principio puede traducirse
en ms posteriormente.
Incertidumbre en las estimaciones: Si se est inseguro de las estimaciones, se puede
incrementar el precio por encima del beneficio normal para cubrir contingencias.
Trminos contractuales: Por ejemplo el permitir que se disponga del source code o no.
Volatilidad de los requerimientos: Se puede reducir precio para ganar un contrato y
luego subirlos cuando los requerimientos vayan cambiando.
Salud financiera: Posibilidad de bajar precios por necesidad de obtener un contrato
por dificultades econmicas.

FACTORES QUE INFLUENCIAN LAS ESTIMACIONES.
Las estimaciones se ven fuertemente condicionadas por varios parmetros, estn expuestos de
ms influencia a menos.
-
Tamao del proyecto.

Tipo del proyecto: No es lo mismo un programa para el Mercadona que uno para la
NASA.
Factores personales.
Lenguaje de programacin.
Otros: Cocomo II.
Tamao del proyecto.

Es el factor ms significativo que contribuye a las estimaciones de esfuerzo y tiempo.
Normalmente el proceso de estimacin que vamos a seguir es el siguiente.
El tamao del cdigo lo podemos cuantificar con unas mtricas, ejemplos de estas mtricas
son las Lneas de Cdigo (LOC), los Puntos de Funcin (FP) y los Puntos de Objeto (OP).
Hay que destacar tambin que el esfuerzo requerido para completar un proyecto crece
exponencialmente con el tamao del proyecto debido a lo siguiente.
Diseconomas de escala.
Normalmente se asume que un sistema 10 veces ms grande que otro requerir 10 veces ms
de tiempo, pero esto es totalmente falso. Cuanto mayor sea el proyecto se requiere ms
comunicacin entre la gente implicada as que el rendimiento de un equipo es inversamente
proporcional a la cantidad de comunicacin que se deba entablar.
Al crecer la comunicacin crece el esfuerzo de forma exponencial. Esto es la diseconoma de
escala, lo contrario de la economa de escala que es asumir que a ms gente, menos tiempo.
Para reducir la diseconoma de escala hay que reducir la escala partiendo el problema en
problemas ms pequeos que requieran menos comunicacin.
Mtricas de tamao. Lineas de Cdigo LOC.

Es una medida propuesta inicialmente cuando los programas se escriban en tarjetas, con una
lnea por tarjeta. Actualmente los lenguajes de programacin permiten escribir varias
sentencias en una lnea o una misma sentencia en varias lneas. No es importante la definicin
de lnea de cdigo sino que siempre se use la misma de forma sistemtica. Adems se asume
que cuantas ms lneas de cdigo habr ms documentacin.
33

Una ventaja de las LOC es que se puede calcular de forma fcil y objetiva pero son totalmente
dependientes del lenguaje de programacin. Ofrecen una estimacin bastante buena pero no
se puede saber lo que vale hasta que ha finalizado la implementacin.
Mtricas de tamao. Puntos de funcin FP.

Estos se basan en una combinacin de elementos de la aplicacin.
-
Entradas externas (EI: External Inputs): Pantallas, formularios, seales de control, a

partir de las cuales los usuarios u otros programas cambian los datos.
Salidas externas (EO: External Outputs): Pantallas, informes, grficos.
Consultas externas (EQ: External Inquiry): Datos no elaborados, por ejemplo datagrids.
Ficheros internos usados por el sistema (ILF: Internal Logical Files): Tablas de la BD.
Ficheros externos al sistema (EIF: External Interface Files): Ficheros externos.
A cada uno de ellos se le asocia un peso en funcin de:

-
Para los EI, EO y EQ se cuentan el nmero de ficheros actualizados o referenciados

(FTR) y el nmero de Data Element Types (DET) o campos.
Para los ILF y EIF se cuentan el nmero de Record Element Types (RET) o agrupaciones
de campos y los DET.
La suma ponderada de los elementos anteriores dan como resultado los puntos de funcin no
ajustados.
Para ajustarlos hay que determinar el VAF o Value Adjustement Factor, para esto se valor del
0 al 5 un total de 14 caractersticas de la aplicacin y se suman los valores resultantes (TDI). Al
final el VAF se calcula como:
VAF = (TDI * 0.01) + 0.65
Para hacer el ajuste FPA = FPNA * VAF.
Para el clculo de los puntos de funcin no ajustados se usan una serie de tablas, como las de
este ejemplo.
34

Si una entrada externa EI tiene 6 DETs y 5 FTRs segn la tabla de EI le corresponde un valor de
6.
Mtricas de tamao. Puntos de objeto o de aplicacin OP.

Los puntos de objeto o puntos de aplicacin son una medida alternativa relacionada con la
funcionalidad cuando se usan lenguajes 4GLs o similares para el desarrollo. Recalcar que los
OP no son clases de objetos de la programacin orientada a objetos as que no contamos ni
objetos creados ni clases.
Se calculan haciendo una estimacin ponderada de:
-
El nmero de pantallas distintas que son visualizadas.

El nmero de informes que se producen por el sistema.
El nmero de mdulos en lenguajes imperativos que deben desarrollarse para
complementar el cdigo de la base de datos.
Esta manera de calcularlos es una de tantas recetas para poder calcularlos. Los OP tienen las
mismas ventajas e inconvenientes que los FP, adems tiene una cierta subjetividad a la hora de
calcularlos dependiendo del estimador y se emplea una granularidad ms gruesa que en los
FPs.
En la asignatura se centran en el clculo de los FP que al fin y al cabo es lo que puede ser ms
largo de hacer en el examen.
Los FP y OP se pueden traducir a LOC mediante el anlisis de datos histricos de la siguiente
manera: LOC = AVC * FP.
Tipo del proyecto.

Este factor es el segundo ms importante a la hora de hacer estimaciones. Los proyectos ms
complejos requieren mayor esfuerzo y suelen tener menos productividad.
Podemos tener proyectos del mismo tamao pero de diferente dificultad, cun ms difciles
sean la productividad tiende a ser menor, lo que es lo mismo, hay que pasar ms tiempo
pensando las lneas de cdigo, estas requerirn ms esfuerzo.
La productividad es una medida de la velocidad a la que los ingenieros implicados en el
desarrollo del software producen dicho software y su documentacin asociada. Una cosa que
NO es la productividad es un indicador de calidad. Bsicamente medimos la funcionalidad til
por unidad de tiempo: Productividad = tamao/esfuerzo(pm).
35
Factores personales.
Es el tercer factor ms significativo que contribuye a las estimaciones. En la siguiente imagen
se observan diferentes factores sobre el personal y como estos pueden afectar positivamente
disminuyendo el esfuerzo (zona azul) y negativamente aumentndolo (zona gris). La zona
nominal sera la lnea negra, es decir, por ejemplo, si la continuidad del personal es muy baja el
esfuerzo se ve aumentado en un 29% sobre el valor normal (lnea negra).
Lenguaje de programacin.
La experiencia en el lenguaje de programacin y herramientas especficas usadas en el
proyecto tiene un efecto alrededor de un 40% sobre el ratio de productividad del proyecto.
Algunos lenguajes producen ms funcionalidad por lnea que otros.
Dependiendo del nivel de soporte de las herramientas automticas usadas con el lenguaje se
puede incrementar hasta en un 50% el esfuerzo requerido.
Los programadores que usan lenguajes de programacin interpretados suelen ser ms
productivos que los que usan lenguajes compilados.
36

Otras influencias. Factores de ajuste COCOMO II.
Esta parte ser vista con detalle posteriormente.
CONSIDERACIONES ESPECFICAS.
Tenemos que tener claro qu es lo que queremos estimar, debemos conocer las incgnitas a
despejar y pueden venir por dos lados diferentes.
Por un lado dadas unas funcionalidades a implementar tenemos que estimar el tamao del
proyecto, el esfuerzo y el tiempo que tardar en entregarse, y partiendo de estas estimaciones
el coste del mismo pensando en los sueldos del personal y otros gastos. Por otro lado se nos
pueden dar una serie de restricciones de presupuesto y tiempo y debemos de ser capaces de
saber la cantidad de funcionalidades que podemos implementar.
A la hora de estimar podemos seguir dos estrategias diferentes, la top-down y la bottomup, en ambas el WBS es importante para ver la jerarqua de tareas.
Estimaciones top-down.
Comienza a nivel de sistema y evala la totalidad de funcionalidades y cmo estas interactan
entre ellas. Adems se puede usar sin conocer la arquitectura ni los componentes que
formarn parte del sistema, es decir, no es necesario conocer los niveles ms bajos del WBS.
Este mtodo tiene en cuenta costes de integracin, gestin de configuraciones y
documentacin, que suelen estar en la parte ms alta del WBS, pero por otro lado puede infraestimar costes relacionados con la resolucin de problemas tcnicos de bajo nivel difciles de
resolver. Puede que abajo del WBS haya algo muy problemtico y que requiera ms
esfuerzo/tiempo/coste del que hemos estimado.
Estimaciones bottom-up.
Pues simplemente lo contrario que el anterior.
Comienza a nivel de componentes y estima el esfuerzo requerido para cada componente.
Dichos esfuerzos se aaden a la estimacin final. Se puede usar cuando la arquitectura del
sistema es conocida y los componentes han sido identificados.
Proporciona estimaciones bastante exactas se el sistema se ha definido con detalle y puede
infra-estimar costes a nivel de sistema (nivel ms alto) como la integracin y la
documentacin.
Con estas definiciones es lgico pensar que las estimaciones top-down se usarn ms cuando
estemos comenzando el desarrollo y la bottom-up cuando vayamos teniendo claros la
arquitectura y los componentes conforme avanzamos el proyecto.
37

Consiguiendo estimaciones exactas.
Debemos seguir unos pasos lgicos a la hora de intentar conseguir las estimaciones ms
exactas posibles.
Todo empieza contando, es lo primero que tenemos que hacer siempre que podamos para
cuantificar el tamao del proyecto. Cuando no se pueda contar calcularemos y en ltima
instancia emitiremos juicios (nada recomendable) pero esto har que lo paguemos caro
porque las agendas planificada y real no se parecern en nada.
Podemos contar muchas cosas, todo esto serian mtricas, nmeros que nos dicen
cuantitativamente el tamao del proyecto, pueden ser desde FPs, casos de uso o talas de la
base de datos.
Por ejemplo, si conocemos las funcionalidades y queremos estimar tamao, tiempo y coste, al
comienzo del desarrollo lo ms sensato es contar los puntos de funcin.
Luego, despus de contar, hemos de convertir estas cuentas en estimaciones. Una vez
contados los FP debemos convertirlo en una estimacin de esfuerzo, para ello necesitamos
calibrar (convertir a estimacin) lo que hemos contado con algn tipo de dato.
Los datos que se suelen usar para calibrar suelen ser:
-
Datos procedentes de la industria.

Datos histricos de nuestra empresa. Vamos a ser ms exactos ya que es nuestra
empresa. Importante trabajar siempre igual para que los datos histricos sean
aceptables.
Datos del proyecto. Podemos fijarnos en los modelos iterativos en estimaciones
pasadas de anteriores iteraciones.
MTODOS DE ESTIMACIN.
Juicio experto.
Con este mtodo se consulta a expertos en tcnicas de desarrollo de software y/o del dominio
de la aplicacin. El experto o expertos emiten un juicio sobre tareas individuales segn una
estimacin bottom-up y para ello puede ser til usar un WBS.
Dentro del juicio experto podemos usar dos variantes, el individual y en grupos,
concretamente en ste ltimo tenemos la tcnica Delphi.
Para asegurar los juicios efectivos hay que usar expertos que realmente han trabajado en lo
que van a estimar, no vale con cuatro personas que hayan ledo sobre el tema, se han tenido
que poner varias veces manos a la obra.
Otra manera de asegurar juicios efectivos puede ser usar la granularidad adecuada y usar
rangos, adems se pueden usar frmulas y comparar las estimaciones con los resultados
reales.
38

Tcnica Delphi.
La tcnica Delphi es el mtodo experto en grupos y se procede de la siguiente manera.
1. El coordinador presenta a cada estimador su formulario de estimacin.
2. Los estimadores preparan individualmente su estimacin.
3. El coordinador modera una discusin sobre cuestiones de estimacin relacionadas con
el proyecto.
4. El coordinador recoge las estimaciones annimamente.
5. El coordinador presenta un resumen de las estimaciones.
6. El coordinador modera una discusin sobre las variaciones.
7. Los estimadores votan annimamente la media de las estimaciones. Si alguno vota NO,
se vuelve al paso 2.
8. El resultado es una nica estimacin, o bien un rango de estimaciones.
Cuando se ve que la estimacin no se ajusta ms, entonces se paran las iteraciones. Aqu abajo
hay un pequeo ejemplo.
sta tcnica se usa para estimaciones iniciales del proyecto ya que se tiene una granularidad
alta al comienzo del mismo y consume mucho tiempo. Es til tambin para estimaciones en
nuevas reas de negocio o nuevas tecnologas.
Se usa adems para proyectos que engloban diversas disciplinas y se consigue una exactitud
posible media.
39

Ley de Parkinson.
La ley de Parkinson se basa en que cuanto ms tiempo me den, me las voy a apaar para
ocuparlo todo. El coste se determina en funcin de los recursos/tiempo disponibles en vez de
evaluaciones objetivas.
Si un SW tiene que entregarse en 6 meses y se tiene a 5 personas el esfuerzo estimado ser de
30pm.
Es adecuado cuando las restricciones prevalecen sobre las caractersticas deseadas del
producto y se puede aplicar a cualquier proyecto consiguiendo una baja exactitud en las
estimaciones.
Modelado algortmico de costes.

Las estimaciones se hacen como una funcin matemtica basada en diversos atributos del
producto, proceso y proyecto.
La frmula bsica que siguen estos modelos es: Esfuerzo = A x SizeB x M.
Donde A es una constante dependiente de la organizacin. La B refleja la diseconomia de
escala y cuanto ms grande sea la curva exponencial de la que ya se habl ser ms
pronunciada.
Size es el tamao del proyecto, y es esencial, ya hemos visto que es el elemento ms
importante a la hora de estimar.
M es informacin adicional para que la estimacin sea ms exacta.
Vamos a estudiar uno de estos modelos, en concreto el de COCOMO (Constructive Cost
Model).
COCOMO.
Con el tiempo se han ido modificando las frmulas de COCOMO pasando de la versin 81 a la
versin II. Bsicamente se han ido haciendo estimaciones de muchos proyectos y sacar
frmulas matemticas que den como resultados esos esfuerzos estimados.
El modelo COCOMO II tiene varios submodelos que generan estimaciones del software ms
detalladas. Estos submodelos son:
-
40
Application composition model. Indicado para proyectos construidos con

herramientas modernas de construccin de interfaces grficos para usuario.
Early design model. Usado cuando los requerimientos estn disponibles pero no es
necesario disponer de la arquitectura completa.
Reuse model. Usado para calcular el esfuerzo de integracin de componentes
reusables.
Post-architecture model. Usado una vez que se disea la arquitectura del sistema y se
dispone de ms informacin del mismo.

Esta ltima es la nica que se va a estudiar en la asignatura, as que en el examen solo
tendremos que justificar este.
Resumen de usos de los diferentes submodelos.
Uso de los diferentes submodelos a lo largo del cono de incertidumbre.
Veamos ahora las frmulas y que es cada parte de ellas. Es importante saber que para el
examen no es necesario saber las formulas de memoria pero si saber justificar qu es cada
parte de las mismas.
41
Vamos a ello. Empezamos por las ecuaciones de tamao para saber el Size de la ecuacin.
Las lneas de cdigo se miden en miles as que es importante que lo que calculemos lo
pasemos a miles, COCOMO se usan para proyectos grandes.
-
KNSLOC: Son las nuevas lneas de cdigo que hay que implementar. Son lneas que no
existen y hay que crearlas.
KESLOC: Son las lneas de cdigo que no estn hechas desde cero sino adaptadas de
versiones existentes.
REVL: Es el porcentaje de cdigo que se ha implementado pero se ha desechado por la
volatilidad de los requerimientos.
KASLOC: Son las lneas de cdigo modificadas.
AT: El porcentaje de lneas de cdigo que se traducen automticamente.
Para las ecuaciones de esfuerzo tenemos lo siguiente.

-
PMAuto: Esfuerzo correspondiente al cdigo automticamente generado.

Mult(SF): Son los factores de escala que se ven a continuacin.
Sum(EM): La suma de los multiplicadores de esfuerzo.
La B se ajusta a 0.91 y ATPROD a 2400.
42
Adems tenemos las ecuaciones de tiempo.
Los multiplicadores de esfuerzo y factores de escala tampoco hay que sabrselos de memoria,
sino que hay que saber identificarlos en un enunciado.
Multiplicadores de esfuerzo y factores de escala.
43

Otra manera de verlos:
EJEMPLOS DE CLCULOS.
Para hacer estimaciones hemos visto que tenemos que seguir una serie de pasos, vamos a ver
ejemplos de estos pasos y diferentes maneras de llevarlos a cabo.
Hemos visto que lo primero que hay que hacer es estimar el tamao del proyecto, nosotros en
la asignatura vamos a hacerlo calculando los puntos de funcin (FP). En prcticas se explica
cmo calcularlos y en el documento de la prctica correspondiente tambin.
El segundo paso es calcular el esfuerzo a partir del tamao que hemos estimado usando datos
histricos de productividad. Si los datos histricos tienen un rango estrecho (la diferencia es un
factor de 3 desde el mayor al menor) se puede usar un modelo lineal.
Por ejemplo, si hemos estimado el tamao y hemos visto que el tamao est entre 65000 y
100000 LOC vamos a estimar el esfuerzo partiendo de datos histricos de otros proyectos.
44
Podemos descartar proyectos, en este caso descartamos el Proyecto C porque 65000/3 =

21666,6 y el Proyecto C tiene 7444 LOC, es demasiado pequeo para compararlo con el
nuestro. Por otro lado el Proyecto E tampoco nos sirve, es demasiado grande, 100000*2 =
300000 as que lo descartamos tambin.
Luego podemos calcular la productividad de cada proyecto, como vimos es el
tamao/esfuerzo y con esto tendremos proyectos con una mayor productividad y proyectos
con una menor productividad. La calibracin se hace dividiendo el tamao menor entre la
mayor productividad y el mayor tamao entre la menor productividad.
En este caso [65000/1612, 100000/986] lo que nos da [40, 101] pm. El resultado es pm porque
lo que estamos dividiendo es LOC entre LOC/PM.
Otra forma de de clculo del esfuerzo de manera ms concreta, es usar Construx, que se usar
en prcticas. Construx utiliza una mezcla entre el modelo Putnam y el COCOMO. Este mtodo
nos permite estimar el esfuerzo a partir de FP, LOC o GUI. Las estimaciones con Construx se
calibran de dos maneras posibles, mediante datos histricos o mediante datos provenientes de
la industria. Es decir, en Construx podemos calibrar introduciendo los datos del mtodo
anterior.
En nuestro ejemplo, con Construx hemos obtenido [65, 94] pm.
El tercer mtodo sera hacer una comparacin con datos de la industria. Existen datos de
proyectos del mismo tipo con dificultad semejante. Podemos ver en este grfico la media y la
media ms una desviacin tpica. Es labor del estimador elegir entre las dos.
En la grfica el eje X representa
las lneas de cdigo y el eje Y el
esfuerzo necesario.
Para nuestro caso, cogemos la
media y si nos movemos hasta
65000 LOC obtenemos 85pm, si
nos movemos hasta las 100000
obtenemos 170pm. De esta
manera usando este mtodo
45

obtenemos una estimacin de [85, 170] pm.
Decir que ste ltimo mtodo es el menos fiable ya que los datos no tienen en cuenta posibles
incidencias dentro de nuestra empresa y factores personales.
Bien, hemos visto tres mtodos de estimar el esfuerzo, pero es importante saber, de cara al
examen tambin que no todos los mtodos de estimacin son iguales. Debemos ponderar y
dar ms peso a las que tienden a producir mejores resultados. NUNCA hay que coger la media
y la ponderacin depende de nosotros, as que eso, lo importante es no dar a todas el mismo
peso. Normalmente Construx es mejor que los datos de proyectos anteriores y ste mejor que
los datos de la industria.
El tercer paso, despus de haber estimado el tamao y el esfuerzo, es estimar el tiempo.
El tiempo se calcula a partir del tamao y del esfuerzo y la ecuacin bsica para la estimacin
del tiempo es: Tiempo_meses = 3 * Esfuerzo_PM^1/3.
Esta frmula se usa para estimaciones tempranas en proyectos medianos o grandes.
El tiempo tambin se puede calcular mediante la comparacin con datos histricos y partiendo
de la frmula anterior podemos obtener otra: Tiempo = Tiempo_proyectos_pasados *
(Esfuerzo_estimado/Esfuerzo_proyecto_pasado)^1/3.
Vamos a ver un ejemplo.
Hemos calculado las estimaciones de tiempo usando la frmula para los proyectos de la tabla
anterior pero sin contar los que habamos descartado. Como vemos calculamos el tiempo
usando el esfuerzo que nosotros habamos estimado y un valor medio que no es necesario
calcularlo.
Luego podemos hacer dos cosas, podemos coger valores medios de las estimaciones baja y
alta y obtener [12, 13.8] meses o coger el peor del bajo y el mejor del alto, esto lo que hace es
ampliar el rango para ser ms exactos y as contemplamos posibles problemas. Se suele usar
este segundo mtodo cuando no tenemos demasiada confianza en los datos. En este caso
sera la estimacin [10.8, 15.3] meses.
46

Bueno, pues ya hemos hecho una estimacin de esfuerzo, y otra de tiempo. Entre estos dos
aspectos debe haber un equilibro siempre.
Acortar el tiempo incrementa el esfuerzo ya que se requiere ms comunicacin y ms
coordinacin y se requieren ms tareas en paralelo. Cuando estimamos tiempo podemos
obtener una agenda nominal que no se debe acortar en ms de un 25% porque sera inviable.
Adems se pueden reducir costes alargando la agenda y reduciendo el personal.
Si bien hemos estimado el esfuerzo y el tiempo del proyecto en general, normalmente luego
debemos asignar estas estimaciones a las diferentes actividades del proceso software.
Normalmente esto se hace partiendo de una tabla de distribucin del esfuerzo para proyectos
de diferentes tamaos y de unos ajustes que depende del tiempo del proyecto.
De esta manera al asignar esfuerzos a diferentes actividades debemos considerar el tamao
del proyecto, el tipo de proyecto y los tipos de esfuerzo contenidos en los datos de calibracin
usados.
A continuacin se expone la tabla de esfuerzos por actividades en proyectos de diferente
tamao y los ajustes por tipo de proyecto.
47

Vamos a usar estas tablas para asignar el esfuerzo a las diferentes actividades de un proyecto
con 80 000 LOC (1450 FP) y con un esfuerzo estimado de 80pm.
80 000 LOC son 80 KLOC asi que en la primera tablas vemos que estamos entre 25 y 125 KLOC.
Para cada actividad el porcentaje ser la media entre estos dos valores. De esta manera
-
Requerimientos: (4+7) / 2 = 4.4%.

Arquitectura: (14+15)/2 = 14.5%.
Construccin: (49+44)/2 = 46.5%.
Pruebas: (23+23)/2 = 23%.
Gestin: (10+11)/2 = 10.5%.
Ahora, con los ajustes, vamos a rellenar la siguiente tabla:
Para facilitar la tarea lo he hecho con MS Excel.
48

Tema 3: Estimaciones. Ejemplo de COCOMO
49

Este ejercicio es el que est en las transparencias de la asignatura, concretamente en el Tema
3, pero en las transparencias hay algn error que otro (lo que no quiere decir que esto est
libre de errores por lo que agradecera que si hay alguno, me lo indicaseis).
Bsicamente se trata de hacer estimaciones usando el modelo COCOMO haciendo uso de sus
frmulas y toda la tropa.
Antes de nada vamos a recordar las frmulas que, importante, no hace falta sabrselas de
memoria para el examen, pero s saber identificar cada parte de ellas.
Recordemos que la ecuacin bsica de esfuerzo en los modelos algortmicos es Esfuerzo = A x
Size^B X M.
Donde A es una constante establecida por la organizacin, Size el tamao del proyecto, B el
factor de escala y un multiplicador de esfuerzo.
Aqu las formulas del modelo COCOMO.
Ecuaciones de Esfuerzo.
Lo importante, saber qu es cada cosa.

En la ecuacin de PMns se refiere a que es la agenda nominal, es decir, sin contemplar el
multiplicador SCHED.
La E es el factor de escala que se calcula como se indica en la frmula de E, donde B siempre
estar calibrada a 0.91 en nuestro caso, y el sumatorio de los 5 factores de escala que veremos
a continuacin y que s hay que aprendrselos y sobre todo saber identificarlos en un texto.
Por otro lado, al esfuerzo nominal habra que sumarle el esfuerzo de las lneas generadas
automticamente calculndose como se indica y siendo ASLOC el nmero de lneas de cdigo
adaptadas, siento AT el porcentaje automticamente traducido y ATPROD un valor por defecto
referente a la productividad de la traduccin automtica, ajustada a 2400 en nuestro caso.
Una vez calculado esto, si lo tenemos, debemos calcular el tamao haciendo uso de las
siguientes frmulas.
50
Donde REVL es el porcentaje de cdigo desechado por la volatilidad de los requerimientos.

KNSLOC los miles de nuevas lneas de cdigo.
KESLOC los miles de lneas de cdigo equivalentes, por ejemplo de un mdulo a parte, esta
parte se usar para el anlisis de la reusabilidad.
Para calcular KESLOC tenemos que multiplicar KASLOC que son las miles de lneas adaptadas
por lo que indica la frmula siendo AT el porcentaje traducido automticamente y AAM un
factor de ajustamiento de adaptacin.
Este ltimo se calcula como se indica siendo AA el grado de asimilacin, SU el porcentaje de
entendimiento del software, DM el porcentaje del diseo modificado, CM el porcentaje de
cdigo modificado y IM el porcentaje de integracin y pruebas modificadas.
Ya, por ltimo, podemos calcular tambin el tiempo de desarrollo siendo:
Siendo SCED el multiplicador de esfuerzo de compresin o dilatacin de la agenda. Lo veremos

ms tarde en el ejemplo.
Por otro lado tenemos los multiplicadores de esfuerzo y los factores de escala, estos si hay que
sabrselos como dije, y adems saber identificarlos en un texto de algn ejercicio, yo para
aprendrmelos uso la siguiente manera.
Tal y como estn en las transparencias los divido en cuatro grupos.
-
51
Producto. CRDDR
o CPLX. Complejidad del Producto.
o RELY. Fiabilidad requerida por el software.
o DOCU. Extensin de la documentacin necesaria.
o DATA. Tamao de la base de datos usada.

-
52
o RUSE. Porcentaje requerido de componentes para reutilizacin.

Computador. TPS
o TIME. Restricciones de tiempo.
o PVOL. Volatilidad de la plataforma de desarrollo.
o STOR. Restricciones de memoria.
Personal. APPPAL
o ACAP. Capacidad de anlisis.
o PCON. Continuidad del personal.
o PCAP. Capacidad de programacin.
o PLEX. Experiencia en la plataforma.
o APEX. Experiencia en el dominio de la aplicacin.
o LTEX. Experiencia en el lenguaje de programacin y herramientas.
Proyecto. TSS
o TOOL. Uso de herramientas software.
o SCED. Compresin de la agenda.
o SITE. Extensin de la aplicacin (local, metropolitana) y comunicacin
requerida.
Factores de escala. PRPTF
o PMAT. Madurez del proceso de desarrollo.
o RESL. Resolucin de riesgos y arquitectura.
o PREC. Precedentes, experiencia de la organizacin en el tipo de aplicacin.
o TEAM. Cohesin del equipo.
o FLEX. Flexibilidad en el desarrollo.

Ejercicio.
LA aplicacin que vamos a desarrollar es una para automatizar el pago de impuestos, a partir
de ahora lo conoceremos como API.
Se ha realizado un anlisis previo de factibilidad, los requerimientos han sido validados con
prototipos y se ha realizado un diseo preliminar.
Se nos ha proporcionado una estimacin de tamao de 281FP siendo la equivalencia en
lenguaje Java de 53LOCs por cada FP. Adems hay un compromiso de entregar el proyecto en
6 meses o menos lo que tendremos que ver si se puede o no.
Por ltimo sabemos que se trata de una aplicacin standalone que se distribuir en CD y va
Internet.
Con esto sabemos que como se ha hecho un diseo preliminar tenemos que usar el modelo
Post-arquitectnico, aunque de hecho, en la asignatura solamente usaremos este modelo.
Por otro lado sabemos que el tamao de la aplicacin en lneas de cdigo ser 281 x 53 =
14893 LOCs o lo que viene siendo lo mismo 14.9 KLOCs (en Cocomo trabajamos en miles de
lneas).
Y se trata de una aplicacin standalone por lo que no requerir ms comunicacin ni extensin
que la de un edificio de oficinas.
Clculo del factor de escala.
NOTA: Luego siempre nos tendrn que dar una especificacin de la aplicacin de donde
tendremos que interpretar y sacar los multiplicadores de esfuerzo y los factores de escala.
Vamos a empezar por los factores de escala, recordamos que son 5 (PRPTF: pmat, resl, prec,
team, flex). Las especificaciones las podremos dividir en los 4 grupos anteriormente nombrados
(Producto, Computador, Personal, Proyecto).
El personal actual de la organizacin es un personal contratado de una compaa local con
nivel 2 CMM. Dicho personal tiene experiencia en el dominio de la empresa (por lo menos tres
aos) y tienen experiencia previa como desarrolladores en Java (tambin 3 aos como
mnimo).
Nuestra empresa adems sufre una alta movilidad de los trabajadores, concretamente
superior al 30% por ao y tienen pocas habilidades como analistas.
Adems hay tres jefes programadores que entran en conflicto con los lderes de grupos y
programadores ms jvenes, estos conflictos son a menudo.
Por otro lado aunque consideramos el proceso de desarrollo importante, no interferimos
regularmente en este aspecto y la empresa est muy familiarizada con este tipo de
aplicaciones.
53

De arriba a bajo tenemos los factores: PMAT, TEAM, FLEX y PREC. Para RESL como no est
tomaremos un valor intermedio posteriormente.
54
Clculo de los multiplicadores de esfuerzo.

Debemos ahora identificar los multiplicadores de esfuerzo.
El personal actual de la organizacin es un personal contratado de una compaa local con
nivel 2 CMM. Dicho personal tiene experiencia en el dominio de la empresa (por lo menos tres
aos) y tienen experiencia previa como desarrolladores en Java (tambin 3 aos como
mnimo).
Nuestra empresa adems sufre una alta movilidad de los trabajadores, concretamente
superior al 30% por ao y tienen pocas habilidades como analistas.
Adems hay tres jefes programadores que entran en conflicto con los lderes de grupos y
programadores ms jvenes, estos conflictos son a menudo.
Por otro lado aunque consideramos el proceso de desarrollo importante, no interferimos
regularmente en este aspecto y la empresa est muy familiarizada con este tipo de
aplicaciones.
De arriba a bajo en naranja, tenemos APEX, LTEX, PCON y ACAP, adems tenamos SITE al ser
standalone.
Calculamos ahora el valor del multiplicador de esfuerzo.
55
Nos quedara calcular SIZE, pero como no tenemos cdigo desechado ni lneas equivalentes, el
tamao es el que hemos calculado con anterioridad.
Clculo de la estimacin de esfuerzo.
Nos queda el siguiente clculo.
56
Anlisis de sensibilidad.
Se nos pide ahora ver qu pasa cuando los requerimientos de documentacin son mnimos y
cuando son mximos y ver lo que pasa con el esfuerzo.
Adems tambin se nos pide el ahorro de esfuerzo que podramos tener si la madurez del
proceso es de CMM 4 lo que su valor seria 1.56. Debemos calcular de nuevo el factor de
escala.
Anlisis de reusabilidad.
Nota: vamos a ver qu pasa ahora, si merece la pena hacer uso de un componente existente
que sustituya una parte de nuestro cdigo o no.
Un aspecto de la aplicacin puede satisfacerse adaptando un software existente
recientemente desarrollado denominado Calculadora de Tasas Declarables (CTD). Si la usamos,
un applet de Java de 4000LOC podra satisfacer aproximadamente un 20% de la funcionalidad
requerida (un 20% de los UFP necesarios).
Se estima que el rediseo del applet sera aproximadamente menos del 20%, y que la cantidad
de cdigo a reescribir sera no ms de un 30%. Adems la integracin y pruebas para
comprobar el rendimiento con los cambios introducidos no requerirn ms de un 25% de
esfuerzo adicional.
Debido a la elevada rotacin del personal, la gente que desarroll CTD ya no estn contratadas
por nuestra organizacin, y el personal actual tiene una familiaridad limitada con CTD, sin
embargo hay una buena correlacin entre API y CTD ya que siguen los mismos estndares de
documentacin.
57
Desarrollando desde 0, tendramos que implementar el 20% de 14.9 = 2.98KLOC o

aproximadamente 3KLOC o 3 000 lneas de cdigo desde 0 para satisfacer esas necesidades.
Quedndonos la frmula del tamao como indico a continuacin.
En cambio si adaptamos el CTD nos quedara como sigue.
Tenemos que calcular entonces KESLOC, que recordamos, las lneas equivalentes de la
funcionalidad a sustituir y que resolvemos en el siguiente clculo.
Para calcular AAM tenemos que seguir las siguientes frmulas.
Para calcular AAF hemos resaltado en el texto del anlisis de reusabilidad en azul, y en orden,
DM (modificacin del diseo), CM (cdigo modificado), IM (pruebas modificadas).
Los valores de AA, UNMF y SU los tenemos que elegir en una tabla a partir de lo que diga el
texto, de esta manera elegimos un AA intermedio, un UNFM mayormente no familiar debido a
58

que no estn contratados los desarrolladores del CTD y un SU alto por la buena correlacin
entre la documentacin.
Ya solo nos queda calcular.
59
Esto quiere decir que en las funcionalidades que se pueden adaptar podemos ahorrarnos un
50% de cdigo.
Para ver el ahorro de esfuerzo debemos calcular el esfuerzo con el tamao usando la
adaptacin del componente CTD.
Clculo del tiempo.

Ahora, por ltimo, debemos estimar el tiempo de desarrollo usando la frmula que est al
inicio del documento.
Nos haban dicho que tenamos que entregar en 6 meses o menos, pero esto es imposible ya
que la agenda nominal no se puede acortar ms de un 25% y la estaramos acortando ms de
un 50% si entregamos en 6 meses.
Como mucho podramos entregar, a costa de incrementar el esfuerzo, en 9.4 meses.
60

Tema 4: Gestin de Configuraciones
61

Definiciones.
Si recordamos el modelo UP, la gestin de configuraciones era una de las disciplinas de
soporte que existan y se hacan a lo largo de todas las fases.
Esta disciplina, la gestin de configuraciones, consiste en el desarrollo y uso de estndares y
procedimientos para gestionar la evolucin de un sistema software durante y despus de la
entrega del mismo al cliente.
Los estndares son prcticas comnmente aceptadas porque han sido probadas y se ha
comprobado que efectivamente cumplen sus objetivos de una manera adecuada, decir
adems que los estndares van evolucionando con el tiempo conforme la gente los va usando
y subsanando los posibles problemas. Estos estndares nos ofrecen algunas ventajas.
a) Encapsulan las mejores prcticas. Todo el mundo lo usa porque confa en ellos, han
sido probados y se conoce bien.
b) Permiten continuidad en el trabajo. Al establecer una norma, todos los trabajadores
trabajan de la misma manera. Por ejemplo, al llegar un nuevo desarrollador ste
trabajar con los mismos criterios.
c) Constituyen un marco para garantizar la calidad. Al usar las mejores prcticas la gente
que sabe que se usa el estndar tienen cierta confianza en nosotros.
Los procedimientos definen cmo hacer algo, son actividades que juntas tienen un propsito u
objetivo comn. Existen una serie de procedimientos estndares de diferente mbito, como
local, nacional, internacional.
El objetivo de la gestin de configuraciones es controlar los costes y esfuerzo implicado en la
realizacin de cambios en el sistema. Esta gestin de configuraciones comienza con el inicio
del proyecto y acaba cuando el software ya no est en circulacin. Es decir, cuando ya no se
usa never more.
Por otro lado, no hay que confundir la gestin de configuraciones con el mantenimiento ya
que este segundo es hacer los cambios al sistema cuando este se ha entregado al cliente
mientras que la gestin de configuraciones implica el cmo manejar la gestin de esos
cambios. Por otro lado el mantenimiento solamente empieza cuando se ha entregado el
software al cliente.
Si mezclamos el tema de los modelos de proceso y el de gestin de configuraciones sta ltima
est fuertemente influenciada por los modelos.
-
62
Cascada: En un modelo en cascada el SW se construye una sola vez durante todo el

proceso.
Iterativo o Incremental: Se construye una vez en cada iteracin.
gil: Los procedimientos deben ser menos rgidos para que consuman menos tiempo.

Elementos de configuracin.
Son aquellos documentos que se van a requerir para un futuro mantenimiento. Ser cualquier
documento que se haya desarrollado a lo largo del proceso de desarrollo y es susceptible de
tener cambios, puede ser cualquier fichero como el cdigo, diagramas de clases, entidades
relacin. Cualquier artefacto.
Cualquier elemento de configuracin que ha sido aceptado para formar parte de la base de
datos de configuracin del sistema se convierte en lnea base (cualquier cambio que se quiera
hacer tiene que pasar por una serie de pasos antes).
Esto ltimo es as porque cuando un artefacto pasa a ser lnea base es visible por todos los
miembros del grupo y por eso cuando hay que hacer algn cambio debe seguir algn
procedimiento.
Tareas del gestor de configuraciones.

Dependiendo del tamao del proyecto puede haber una persona que hace las tareas
especficas del gestor de configuraciones pero si no existe este rol es el gestor del proyecto el
que se encarga de ellas. Estas tareas que sern explicadas a continuacin con ms detalle son
las siguientes.
-
Planificacin de la gestin de configuraciones.

Gestin de los cambios del sistema.
Construccin del sistema.
Gestin de nuevas versiones.
Planificacin de la gestin de configuraciones.

Es la primera tarea del gestor de configuraciones y como cualquier planificacin tenemos que
responder a las preguntas: QUE, COMO, CUANDO y QUIEN.
Un plan de GC describe los estndares y procedimientos usados para la GC. El punto de partida
para la planificacin debe ser la eleccin de los estndares.
-
Definir QUE se va a gestionar y cmo se identifican los elementos de configuracin. La

identificacin de los EC implica darles un nombre para que cuando los veamos nos de
la mxima informacin de lo que contiene sin tener que abrir el fichero o documento.
Todos los documentos que van a ser tiles para una futura evolucin del sistema
deberan ser controlados por el sistema GC.
Definir QUIEN ser el responsable de los procedimientos de GC.
Definir las polticas de control de cambios y versiones (CMO y CUANDO). Es decir,
definir los algoritmos a seguir a la hora de hacer un cambio.
Adems se identifican las herramientas que se van a usar y se establece cmo usarlas as como
describe la estructura de la BD de configuraciones.
63

La identificacin de los elementos de configuracin se pueden hacer de varias maneras pero
cada una tendr sus ventajas e inconvenientes. Quiz una aproximacin jerrquica sea la ms
flexible aunque tiene los inconvenientes de que es particular para cada proyecto y puede ser
difcil identificar componentes relacionados.
Adems hablando de estndares y de procedimientos aqu se muestra un ejemplo de lo que

podra ser un formulario de peticin de cambios y una manera de registrar los cambios en el
cdigo fuente de los archivos.
64

Dentro de la planificacin de la GC hemos visto que hay que elegir las herramientas a usar
para la gestin de configuraciones. Algunos ejemplos de estas herramientas pueden ser CVS
que implementa un control de versiones de los EC manteniendo el registro de todo el trabajo y
los cambios el nos ficheros que forman el proyecto. Permite adems que distintos
desarrolladores colaboren.
Otra herramienta es ANT que se usa para la construccin del sistema y facilita el trabajo a la
hora de realizar tareas mecnicas y repetitivas. Es similar a MAKE pero para Java.
La base de datos de configuraciones registra cualquier informacin relevante relacionada con
las configuraciones y sus elementos. Permite evaluar el impacto de los cambios en el sistema y
generar informes sobre el proceso de GC.
No incluye informacin sobre los elementos de configuracin, sino que registra informacin
sobre los usuarios de los componentes, los clientes, la plataforma de ejecucin, los cambios
propuestos. Se debe posibilitar el contestar a consultas relacionadas con este tipo de
informacin.
Gestin de los cambios del sistema.

El objetivo es seguir la pista a los cambios realizados y asegurar que se implementen de la
forma ms efectiva. Se establecen procedimientos para analizar los costes y beneficios de los
cambios propuestos aprobando los que son relevantes y registrando qu componentes del
sistema sufren cambios.
El procedimiento se inicia cuando el EC se entrega al grupo de GC, es decir, cuando se
convierte en lnea base pasando a formar parte de la BD de configuraciones.
Un posible procedimiento, pero que no el nico, puede ser el siguiente:
El control de cambios tambin puede ser soportado por herramientas CASE, estas
herramientas deben facilitar que los documentos correctos deben pasarse a las personas
correctos en el tiempo correcto.
65

Deben cumplir una serie de caractersticas, como poseer un editor, un sistema workflow, una
base de datos de cambios y un generador de informes. Ejemplos pueden ser Bugzilla y
Rational ClearRequest.
Construccin del sistema.

Es el proceso de compilar y linkar los componentes software en un sistema ejecutable, de esta
manera podemos concluir que diferentes sistemas se pueden obtener de diferentes
combinaciones de componentes.
Es un proceso soportado por herramientas automticas conducidas por scripts de compilacin.
Adems hay que distribuir los ejecutables en las mquinas correspondientes y en los
directorios correspondientes.
Al construir un sistema tenemos que tener claras las respuestas a las siguientes preguntas:
-
Se han incluido todos los componentes?

Estamos usando la versin adecuada de los componentes?
Estn disponibles todos los ficheros de datos (bases de datos)?
El flujo que sigue la construccin del sistema puede ser este:
Vemos que es el sistema de gestin de versiones el que usa los componentes adecuados para
compilar posteriormente y linkar los objetos. Todo parte de un script de construccin que
indica las rdenes que hay que ir ejecutando.
Y hablando de estos scripts existe soporte CASE para la construccin del sistema con el
objetivo de automatizar el proceso de construccin para reducir los errores humanos y el
tiempo requerido. Estas herramientas deben tener en comn:
-
Lenguaje de especificacin de dependencias y su intrprete.

Soporte para la seleccin e instanciacin de herramientas.
Compilacin distribuida.
Gestin de objetos derivados. Refirese a que si no se ha modificado un archivo no se
compila.
Un ejemplo de estas herramientas es ANT. Es una herramienta para la construccin de

programas basada en Java independientemente de la plataforma.
66

Podemos hacer una comparacin con make, para que nos quede ms claro. Make usa un
fichero llamado makefile que contiene el script de ejecucin, en cambio ANT usa xml dentro
de un fichero llamado build.xml.
Los elementos principales de un fichero build.xml son:
-
Project: Obligatorio, elemento central. Cada Project tiene uno o ms targets, que se
pueden ejecutar.
Property: es un par nombre-valor que pueden ser definidas por el usuario.
Target: es un conjunto de tasks que se ejecutan y pueden depender de otros targets.
Task: es un cdigo que se puede ejecutar, pueden tener varios atributos haciendo
referencias a las properties.
Para que quede ms claro he hecho una imagen poniendo en ella explicaciones:
67

Gestin de versiones y releases.
Al poder existir diferentes configuraciones para un mismo sistema el gestor de configuraciones
son los responsables de seguir la pista a las diferencias entre las diferentes versiones para
asegurar su correcto mantenimiento y que sean entregadas a los correspondientes clientes en
el momento adecuado.
Una versin es una instancia del sistema que difiere funcionalmente de otra. Esto es que
pueden tener diferentes funcionalidades, rendimiento mejorado o errores reparados o pueden
ser funcionalmente equivalentes pero diseadas para diferentes plataformas. Normalmente
las versiones son visibles en el interior del grupo de desarrollo.
El gestor debe decidir cuantas versiones hay que hacer y cuando hacerlas as como los cambios
introducidos en cada una de ellas.
Una entrega o release es una instancia del sistema distribuida a los clientes, normalmente es
ms costosa pues implica la distribucin del programa a los clientes. Al fin y al cabo es una
versin entregada al cliente.
Para gestionar las versiones y las entregas se deben realizar una serie de actividades.
-
Hay que idear un esquema de identificacin de versiones. No existe uno universal,

hay que elegir alguno teniendo en cuenta ventajas e inconvenientes.
Planificar cuando se debe producir una entrega. Equilibrio entre nmero de cambios y
tiempo transcurrido entre entregas.
Asegurar que los procedimientos y herramientas se aplican adecuadamente. Ver que
se est haciendo bien.
Identificacin de versiones.
Se deben definir procedimientos para identificar las versiones de los componentes de forma
no ambigua. Hay tres tcnicas bsicas.
-
68
Numeracin de versiones: Al componente se le asigna un nmero de versin explicito

y nico. Es el ms usado. Para ver lo que contiene cada versin y los cambios hay que
acudir a una tabla de features donde dice lo que se ha incorporado, quitado, o
subsanado.
Identificacin basada en atributos: Cada componente tiene un nombre y un conjunto
asociado de atributos para cada versin del componente. Los componentes se
identifican por tanto por su nombre y los atributos. Es menos inmediata pero ofrece
ms informacin.
Identificacin orientada al cambio: casa sistema se nombra a partir de los atributos,
pero tambin se asocia con una o ms solicitudes de cambios. Esta opcin es mucho
ms costosa. Est pensada solo para sistemas, no para componentes. Se deben
introducir reglas de consistencia para limitar las combinaciones de cambios.

Planificacin de releases.
El gestor de configuraciones es el responsable de decidir cundo se entrega el sistema a los
clientes, gestionando el proceso de crear dicha entrega y la documentacin asociada.
Una entrega puede incluir:
-
Ficheros de configuracin y de datos.

Programa de instalacin.
Documentacin electrnica y de papel.
Empacado y publicidad.
El coste de una release es superior al de las versiones y nunca debemos asumir que el cliente
dispone de releases anteriores. Es decir, que no hay que asumir que para que vaya la release 2,
el cliente tiene que tener anteriormente la 1.
Como en todo eso de la GC, la gestin de versiones puede ser automatizada con herramientas
CASE. La gestin de versiones implica la gestin de grandes volmenes de informacin para
asegurar que los cambios en el sistema son almacenados y controlados.
Las herramientas de gestin de versiones controlan un repositorio de EC. Para trabajar con un
EC debemos extraerlo en un directorio de trabajo y posteriormente volverlo a introducir.
Las caractersticas de estas herramientas deben ser:
-
Identificacin de versiones y entregas.

Gestin de la informacin almacenada.
Registro del historial de cambios.
Desarrollo independiente.
Soporte para uno o varios proyectos.
CVS es una aplicacin que usa una arquitectura cliente-servidor donde el servidor guarda las
versiones actuales del proyecto y su historial. Los clientes se conectan al servidor para sacar
una copia completa del proyecto, realizar modificaciones, y posteriormente volver la copia al
servidor o repositorio CVS.
Varios clientes pueden sacar copias al mismo tiempo, luego el servidor trata de acoplar ambas
versiones si es posible haciendo un merge. Si se ha modificado la misma lnea el servidor avisa
de ello al segundo en modificarla y este elige en cambiarla o dejar la que est.
Cuando se completa la actualizacin la versin se incrementa en todos los componentes
implicados y se almacena informacin del autor, descripcin y fecha.
Todo este tema del USO de CVS se especificar mejor en el material de prcticas.
69

Tema 6: Automatizacin de las Pruebas
70

Introduccin.
A partir de este tema entramos en un mundillo nuevo dentro de lo que es la asignatura. Nos
hemos saltado el Tema 5 que ser el que veamos el ltimo. Los temas 5, 6 y 7 pertenecen a las
PRUEBAS de un sistema. Y vamos a empezar a ver como se automatizan estas.
Dentro del tema vamos a ver por qu es importante automatiza las pruebas y estudiar una
herramienta para ello, JUnit.
Nos tiene que quedar muy claro qu es JUnit y cmo utilizarlo.
Automatizacin de las pruebas.

En la siguiente imagen podemos ver una panormica general de lo que son las pruebas en
sistemas software. Nosotros nos vamos a centrar en este tema en las pruebas unitarias donde
pretendemos aislar elementos individuales del software del resto del cdigo y determinar si
funcionan exactamente como se esperaba probando cada unidad por separado.
En general, las pruebas consistirn en un proceso para comprobar si la unidad hace lo que
tiene que hacer. Dando unas entradas se tienen que producir determinadas salidas. Si se
producen, todo guay, si no, pues mal.
Como he dicho, nos vamos a centrar en lo del recuadrito donde ejecutaremos las pruebas de
unidad. Como se puede ver en distintas fases del proyecto hay distintos tipos de prueba. De
esta manera una vez de integran las unidades probadas en un modulo, se prueba este para ver
si cumple con el diseo, cuando se integran estos se hace una prueba funcional del sistema
para ver si cumple con los requerimientos funcionales. Posteriormente se comprueba el
rendimiento y requerimientos no funcionales para luego ver si se cumple con los
requerimientos del cliente y por ltimo una prueba de instalacin en el entorno de produccin.
71

Las pruebas de unidad, las de integracin, funcional y de rendimiento las englobaremos en los
otros temas en pruebas de Verificacin del software y las otras dos en Validacin del mismo y
las llamaremos indistintamente pruebas de aceptacin.
Como deca, las unidades ser lo primero que se pruebe siendo ejemplo de unidades los
elementos ms pequeos como funciones, clases, etc.
Es la ejecucin de las pruebas unitarias lo que vamos a automatizar en este tema.
Interesa automatizar las pruebas porque el hacer las pruebas y repetirlas con los mismos
parmetros de entrada cada vez que modifiquemos el cdigo costara mucho tiempo hecho
manualmente cosa que no interesa al gestor interesndole ms consumir poco tiempo en ello.
Los tests automticos se pueden repetir cada vez que el cdigo se modifica haciendo pruebas
de regresin, siendo esto la repeticin de una unidad tantas veces como se modifique el
cdigo estando entonces dicha unidad bien probada.
Por otro lado, al automatizar las pruebas, se puede ampliar la extensin de las mismas
pudiendo probar con mayor nmero de datos de prueba sin tener que hacerlo manualmente.
Habamos dicho tambin que haba que aislar lo mejor posible las unidades, aunque esto no
siempre es fcil, de hecho, a veces incluso es difcil. Para conseguir aislar las unidades y
automatizar las pruebas necesitaremos usar dos conceptos.
Driver:
Es el cdigo que automatiza la ejecucin del conjunto de pruebas preparando los datos de
prueba, realizando las llamadas a las unidades a probar, almacenando los resultados
comprobando que son correctos y generar un informe de las pruebas.
Para que se entienda, sera como un main principal y temporal donde llamamos a las
funciones a probar y vemos si da lo que tiene que dar o no.
Stub:
Es el cdigo que simula parte del programa llamado por la unidad a probar. Simula el cdigo al
que llama y devuelve un resultado.
Por ejemplo seria una funcin de llamada a base de datos, pero que, por ejemplo, nosotros le
ponemos lo que tiene que devolver directamente en lugar de conectar a la BD.
NOTAS: Nuestro objetivo es hacer las pruebas, ver si est bien o mal, no es nuestro trabajo la
depuracin.
No hay que cambiar el cdigo que quiero probar entre pruebas.
72
JUnit 4.
Vamos a lo que vamos. Buscbamos que con unas entradas en concreto nos diese un resultado
esperado.
JUnit es un API de Java que permite crear los drivers (de hecho solo crea los drivers) para
ejecutar los casos de prueba sobre los componentes UP de forma automtica.
Esta herramienta permite implementar las pruebas o tests enviando las entradas a las UP
(parmetros de entrada), nos da respuestas de la ejecucin de la UP (salidas esperadas) y
determina si un test falla o no (informe).
Los tests, se ejecutan a travs de test runners que no son ms que un mecanismo para leer las
pruebas y ejecutarlas registrando y siguiendo la pista de los resultados de los tests.
Resultados.
Los resultados de las pruebas pueden ser varios, en concreto tres:
Pass: El caso de prueba consigue su propsito y que el software a probar funciona tal y como
se esperaba.
Fail: Indica que el caso de prueba consigue su propsito pero el software a probar no funciona
tal como se esperaba.
Error: Indica que el caso de prueba no consigue su objetivo, normalmente por la ocurrencia de
algn evento inesperado o que no se ha escrito correctamente.
73
Usos de JUnit.
JUnit normalmente se usa para aplicar una metodologa TDD (Test Driver Development)
escribiendo siempre un test JUnit y ejecutarlo antes de escribir la UP a probar por lo que es
imperativo automatizar las pruebas.
Cuando ejecutamos las pruebas implementamos el cdigo de forma que sea el mnimo cdigo
requerido para pasar las pruebas.
Si modificamos el cdigo las pruebas las debe pasar igualmente, hacindolo de forma
incremental y haciendo por tanto tests de regresin.
Esta metodologa nos permite hacer una especificacin completa del programa desde el
principio (por ejemplo, al disear las pruebas podemos pensar que pasara cuando a una
funcin le pasamos nmeros negativos).
Tests y ejemplos.
Un test es un conjunto de mtodos Java que implementan el driver para probar las unidades
del sistema.
JUnit usa aserciones (asserts) para informar del resultado de un test, estas aserciones se
implementan en un paquete y por ejemplo ofrece la comprobacin.
-
Igualdad entre objetos.

Referencia a objetos idnticos.
Referencias a objetos null o not null.
Nosotros, de forma obligada por Galipienso, debemos definir un caso de prueba en cada
mtodo de prueba proporcionando unos datos de entrada y un resultado esperado.
El resultado esperado es obligatorio meterlo de forma explcita. Por ejemplo:
74

Vemos que ponemos nosotros los datos de entrada y el resultado esperado. Comprobamos
con un assert que el resultado de la UP y el resultado esperado sean iguales.
Pasos para realizar las pruebas de unidad.
Para hacer las pruebas de unidad tenemos que seguir una metodologa paso a paso.
1. Preparar el entorno de pruebas para satisfacer determinadas condiciones. Por ejemplo
inicializar valores de variables, establecer una conexin de red, etc.
2. Ejecutar el caso de prueba: ejecutar el cdigo a probar usando datos de entrada si se

requieren.
3. Evaluar los resultados obtenidos: comprobar si el resultado esperado es el mismo que
el realmente obtenido.
4. Volver a restablecer el estado del entorno de pruebas a su situacin origina. Por
ejemplo puede ser necesario volver a inicializar ciertas variables para que se puedan
ejecutar los tests.
NOTA: Los mtodos implementados en 1 y 4 se llaman FIXTURES y se ejecutan siempre antes

(before) y despus del mtodo de prueba (after).
Las anotaciones @Before y @After se usan para indicar acciones que se ejecutan antes y
despus de cada mtodo de prueba anotado con @Test. Incluso @After se ejecuta si han
ocurrido excepciones.
Adems se permiten muchos @Before y muchos @After igual que no pueden ser necesarios.
Si tenemos dos mtodos de prueba la secuencia de ejecucin sera:
-
Befores.
Prueba 1.
Afters.
Befores.
Prueba 2.
Afters.
As llegamos a mi BPA! jurjurmuhaha!
75

Ademas de estos fixtures podemos ejecutar una vez antes de todos los mtodos de prueba o
una vez despus de ellos y antes o despus de todos los befores y afters. Esto puede ser til
para inicializar o detener servidores, establecer o cerrar comunicaciones, etc. Siendo casi
siempre actividades que consumen mucho tiempo.
Para ello se usan las anotaciones @BeforeClass y @AfterClass.
Aserciones.
Estn definidas en la clase JUnit Assert:
-
Si una asercin es cierto, el mtodo contina ejecutndose.

Si cualquier asercin es falsa, el mtodo detiene su ejecucin en dicho punto y el
resultado del mtodo de prueba ser fail.
Si se lanza cualquier otra excepcin durante la ejecucin del mtodo el resultado de
dicho mtodo de prueba ser error.
Si no se viola ninguna asercin durante la ejecucin del mtodo el resultado ser pass.
Todos los mtodos de aserciones son mtodos estticos.

Aqu un listado de las posibles aserciones de las que disponemos.
76

Pruebas de excepciones.
Se hace igual que en los otros mtodos, pero despus de @Test debemos indicar entre
parntesis la excepciones perada al ejecutar el mtodo de prueba.
Si no se lanza ninguna excepcin, o bien si tiene lugar una no esperada, el test fallar, si
alcanzamos el final del mtodo sin lanzar excepcin se provoca un fallo en el test.
Por otro lado, si queremos probar el mensaje de la excepcin, o limitar el mbito en el que se
espera la excepcin, capturaremos la excepcin y usaremos la asercin fail si no se lanza la
excepcin.
Es decir, podemos poner fail dentro de un try cuando se debera haber lanzado una excepcin.
Un par de ejemplos ms:

Hacer notar que siempre que estamos
hablando de probar excepciones las
probamos en el mtodo de test por lo
que ser el mtodo de la UP a probar el
que tenga que lanzar el error.
77

Organizacin de los tests en JUnit.
Cada mtodo de prueba representa un nico caso de prueba que puede tener un resultado de
forma independiente. Normalmente todos los tests de una clase Java se agrupan en una clase
separada siguiendo una serie de convenciones siendo la clase a probar Value y la clase que
contiene los tests ValueTest (Calculadora y CalculadoraTest).
Las agrupaciones de tests se llaman SUITES, en estas suites todos los tests de una clase Java se
agrupan en una clase separada.
Y se pueden ejecutar desde el cdigo, desde la lnea de comandos o desde eclipse de las
siguientes maneras.
La integracin de JUnit con Eclipse la veremos en prcticas as como ms ejemplos.

Esto es todo por ahora.
78

Tema 7: Pruebas Dinmicas
79

Introduccin.
En este tema continuamos con las pruebas. Concretamente vamos a hablar de las pruebas
dinmicas de las cuales solamente vamos a practicar dos mtodos. Por otro lado vamos a
introducir brevemente las pruebas estticas viendo un tipo de estas.
En este tema tenemos que terminar conociendo las diferencias entre pruebas estticas y
dinmicas as como saber disear las segundas. Por otro lado dado un proyecto tenemos que
saber disear pruebas de caja blanca y pruebas de caja negra.
Pruebas dinmicas vs pruebas estticas.

Primero de todo vamos a ver la diferencia entre estos tipos de pruebas.
Por un lado tenemos las pruebas dinmicas que solamente se pueden hacer durante la
implementacin ya que necesitamos ejecutar s o s el cdigo fuente a probar para detectar
los fallos, por ello tenemos que disponer del cdigo.
No se puede concluir que hay algn error en el cdigo si no lo ejecutamos con unos datos de
entrada y comprobamos que el resultado real es igual al esperado, por lo tanto solo podemos
usarlas cuando disponemos de un prototipo o un ejecutable del programa.
Por el contrario, las pruebas estticas son aquellas que no necesitan ejecutar el cdigo para
detectar defectos en el cdigo. Normalmente son ms efectivas, detectando ms errores en
menos tiempo.
Como no es necesario ejecutar el cdigo se pueden aplicar en cualquier momento del
desarrollo y pueden resultar ms efectivas en cuanto a coste que las pruebas dinmicas.
El disponer de dos tipos nos pueden llevar a pensar que unas son mejores que otras, pero no
es as, son pruebas complementarias, cada tipo de pruebas detectan un tipo de errores que las
otras no. Si nos dejamos un error usando unas pruebas podemos detectarlo con las otras y
viceversa.
Pruebas estticas: Inspecciones de cdigo.
Estas inspecciones las podemos realizar en cualquier momento del desarrollo y no es necesaria
la ejecucin del cdigo para detectar errores.
Se trata de un estudio a fondo del cdigo que tiene que estar correcto y compilable. Durante
las inspecciones de cdigo hay una serie de roles que desarrollan en proceso de inspeccin.
Roles:
-
80
Desarrollador: Los autores del cdigo tienen que estar presentes ya que ellos sern los
que mejor comprenden el cdigo.
Moderador: Conduce y organiza la reunin y registra los resultados decidiendo si no
hay errores, si los hay pero no son importantes o los hay graves.
Inspector: Miran el cdigo, lo analizan y dicen lo que han encontrado en l.

Proceso:
-
Preparacin individual: Es trabajo del moderador repartir el cdigo a priori para que
cada rol se lo estudie a fondo para cuando llegue la reunin saber de que se va a
hablar y solamente comentar lo que se ha encontrado y no malgastar tiempo.
Recopilacin de resultados: se trata de poner en comn lo que se ha encontrado
teniendo como objetivo tratar el mayor nmero de errores en el menor tiempo
posible.
Proceso corto: No debe ser un proceso de ms de dos horas.
Los artefactos a inspeccionar se examinaran usando unas tcnicas de lectura, siendo una de
ellas las listas de comprobacin de errores que sin simples listas de preguntas a las que
tenemos que responder s o no, por ejemplo, estn todas las variables inicializadas? Estas
listas de comprobacin son una estandarizacin de las comprobaciones y dicha
estandarizacin facilita posteriormente la automatizacin de la inspeccin.
Las listas de comprobacin se pueden ir modificando con el tiempo a medida que van saliendo
nuevos tipos de errores, pero un ejemplo estndar de lista de comprobacin puede ser el
siguiente:
-
81
Errores de datos.
o Estn todas las variables inicializadas antes de que se usen?
o Todas las constantes tienen nombre?
o El primer elemento de los arrays empieza por 0,1 o algo ms?
o La cota superior de los arrays es longitud-1 o longitud?
o Si se usan cadenas de caracteres, hay un delimitador asignado
explcitamente?
Errores de control.
o Para cada condicin, la condicin es correcta?
o Terminarn todos los bucles?
o Las sentencias compuestas, tienen los parntesis bien puestos?
o En los switch case se contemplan todos los caso?
Errores de entrada/salida.
o Las variables de entrada tienen todas valor antes de usarlas?
o Las variables de salida tienen un valor asignado antes de ser enviadas a la
salida?
Errores de interfaz.
o Las llamadas a las funciones, tienen el nmero correcto de parmetros?
o Coinciden los tipos de parmetros?
o Los parmetros estn en el orden correcto?
o Si los componentes acceden a memoria, tienen todos los mismos modelos de
memoria compartida?
Errores de memoria.
o Si una estructura enlazada se modifica, todos los enlaces a esta estructura se
reasigan todos?
o Si se usa memoria dinmica, se ha reservado memoria correctamente?

-
o Se libera el espacio despus de usarlo cuando no se usa ms?

Errores de manejo de excepciones.
o Se han tenido todos las opciones que pueden provocar error en cuenta?
Pruebas estticas automticas.

Como haba dicho antes, si se estandarizan las pruebas son susceptibles de ser automatizadas
pues estandarizar consiste en sistematizar las cosas y a partir de ah siempre lo haremos igual
de forma mecnica.
Para automatizar las inspecciones usaremos analizadores estticos, herramientas basadas en
el procesamiento de ficheros fuente en formato de texto. No solo detectaremos errores sino
que tambin podemos detectar cdigo basura.
Las etapas a realizar durante un anlisis esttico son las siguientes.
-
Anlisis del flujo de control: Comprobaciones de bucles con varias entradas y salidas,
cdigo no alcanzable, etc.
Anlisis de uso de los datos: deteccin de variables no usadas, escritas dos veces sin
asignaciones intermedias, variables declaradas pero no usadas, etc.
Anlisis de la interfaz: Comprobacin de inconsistencias de los prototipos de las
funciones y procedimientos y su uso.
Anlisis de flujo de informacin: Identifica las dependencias entre las variables de
entrada y salida.
Anlisis de caminos: Identificacin de caminos y sentencias ejecutadas en dichos
caminos.
Ejemplos de herramientas estticas automticas.

Disponemos de varias herramientas para realizar inspecciones de cdigo.
Tenemos a Lint para cdigo C, PMD para Java detectando cdigo duplicado, cdigo inaccesible,
expresiones complejas y posibles errores.
CPD para Java tambin detecta duplicidades, Crap4J descubre qu parte del cdigo es difcil de
mantener y Sonar para Java, Flex, PL, C++) es la ms potente de todas, ya que contempla todo
lo anterior en una sola herramienta.
Pruebas dinmicas.
Este tipo de pruebas si las vamos a practicar en prcticas. Como habamos dicho se necesita la
ejecucin del cdigo para detectar la presencia de errores. El proceso de pruebas requiere
previamente un diseo de casos de pruebas. Siendo este diseo la eleccin de las entradas
que creemos sern convenientes y saber el resultado esperado obteniendo los casos de
prueba.
82
Casos de prueba = entradas + salidas esperada.

Podemos resumir el proceso con la anterior imagen.
Siendo el disear los casos de prueba donde nos vamos a centrar en este tema y siendo los
otros tres pasos lo que automatiza JUnit.
Para disear los casos de prueba no basta con elegir datos de entrada aleatorios ya que
gastaremos mucho tiempo para nada, si elegimos valores aleatorios estructuralmente
podemos no probar alguna parte de cdigo donde pueda haber un error, por ejemplo, nunca
entraramos en un bucle o en una rama de un if, por otro lado, si elegimos los datos
aleatoriamente podemos estar probando siempre una cosa que va bien y quiz con una
prueba que pruebe esa parte sabemos que est bien as que no sera necesario probar con ms
datos de entrada.
Por ello debemos de ser sistemticos a la hora de elegir los datos de entrada y hacer uso de
los particionamientos de estos datos agrupando los datos de entrada que llevan a la misma
conclusin.
Las pruebas sistemticas dependen de estos particionamientos representando conjuntos de
posibles comportamientos del sistema. Debemos elegir muestras significativas de cada
particin asegurndonos de cubrir todas las particiones. En este tema descubriremos como
identificar las particiones.
Destacar que hay muchos mtodos de pruebas dinmicas garantizando algo cada mtodo y
unos mtodos garantizas cosas que otros no.
83

Mtodos de prueba de CAJA BLANCA.
Las pruebas de caja blanca se llaman tambin pruebas estructurales obteniendo los casos de
prueba a partir del CODIGO de la unidad a probar.
Se analiza la estructura del cdigo a probar para obtener los datos de entrada necesitados. Se
necesita tener la UP implementada, es decir, necesitamos su cdigo.
En la siguiente imagen se puede ver a lo que nos referimos, a partir del cdigo obtenemos los
datos de entrada, pasndoselos al cdigo para ejecucin y viendo las salidas de los tests.
Pruebas de caminos.
Nuestro objetivo sern, principalmente, con el menor nmero de pruebas obtener el mayor
numero de errores.
La prueba de caminos es un mtodo de caja blanca cuyo OBJETIVO es ejecutar cada camino
independiente en el cdigo a probar garantizando que se ejecutan todos ellos. Si sabemos que
se ejecutan todos estos caminos estaremos ejecutando todas las sentencias del cdigo al
menos una vez y que todas las condiciones se evalan a cierto y falso.
Un camino independiente es un camino en un grafo de flujo que representa un camino del
programa que difiere de otros caminos en al menos un nuevo conjunto de sentencias y/o una
nueva condicin.
Los pasos a seguir para disear las pruebas son mecnicos y secuenciales, son los siguientes:
a)
b)
c)
d)
Construir el grafo de flujo del programa.

Calcular la complejidad ciclomtica CC.
Obtener los caminos independientes.
Determinar los datos de entrada de forma que se ejerciten todos los caminos
independientes.
e) Determinar el resultado esperado.
El resultado del diseo de las pruebas de camino se presentarn en tablas como la siguiente
siendo los datos de entrada y resultados esperados DATOS REALES Y CONCRETOS, MUY
IMPORTANTE, si no es as en el ejercicio del examen se tendr un CERO.
84
Con estos datos se los pasaremos a JUnit.

Grafo de flujo.
Los grafos de flujo representan el flujo de ejecucin de la unidad a probar, los nodos de estos
grafos representan decisiones (condiciones) y sentencias consecutivas y los arcos representan
el flujo de control.
Es importante para el examen tener CLARO que cada nodo SOLAMENTE puede representar
UNA SOLA DECISIN.
Complejidad Ciclomtica CC.
Es una mtrica que proporciona una medida de la complejidad lgica de un componente
software y se calcula a partir del grafo de flujo de la siguiente manera:
CC = nmero de arcos nmero de nodos + 2.
El valor CC indica el mximo nmero de caminos independientes en el grafo. Por ejemplo, para
una sentencia if:
Obtencin de caminos independientes.

Hay que buscar tantos caminos independientes como valor obtenido por la CC, aunque pueden
salir menos caminos siendo la CC la cota superior de caminos independientes. Con esos
caminos recorreremos todos los nodos y todas las aristas del grafo, por ejemplo:
85
Obtener datos de entrada que ejerciten los caminos independientes.

Simplemente, una vez obtenidos los caminos tenemos que decidir los datos de entrada que
obliguen a recorrer cada camino y poner el resultado esperado.
Ejemplo:
86
87

Mtodos de pruebo de CAJA NEGRA.
Recordamos que seguimos dentro de las pruebas dinmicas que son las que necesitan
ejecutar el cdigo para obtener los casos de prueba, adems, en las de caja blanca
necesitbamos tener el cdigo fuente visible para hacer los casos de prueba, cosa que no es
necesaria en las pruebas de caja negra.
En estas pruebas se obtienen a partir de las especificaciones de la unidad a probar tratando a
esta como una caja negra de la que solo conocemos sus entradas y sus salidas.
Con este tipo de pruebas tenemos la ventaja de que podemos crear los casos de prueba antes
de implementar el cdigo cosa bastante til si queremos seguir una metodologa de desarrollo
guiada por las pruebas.
Dentro de este tipo de mtodo vamos a ver uno en concreto, la prueba de particiones
equivalentes.
Prueba de particiones equivalentes.
Este mtodo garantiza que probamos con todas las particiones necesarias en los datos de
entrada. Este es su objetivo, probar todas y cada una de las particiones de entrada y salida
tanto vlidas como invlidas.
Todos los datos que pertenecen a una particin de entrada tienen el mismo comportamiento
dentro de la caja negra a probar, es decir, si una particin vlida son los nmeros positivos
cualquier valor dentro de ese grupo har que el programa se comporte igual y provoque la
misma salida (suponiendo que solo se tenga una entrada).
Pasos para disear las pruebas.
Para crear los casos de prueba primero tenemos que crear las particiones de entrada y de
salida vlida y no vlida para cada uno de los parmetros de entrada y de salida.
Luego hay que combinar esas particiones de entrada y de salida cumpliendo una serie de
restricciones:
-
88
Como mximo solo se puede probar una clase invlida en cada uno de los casos de
prueba (cada fila de la tabla de casos de prueba puede contener como mucho una
entrada no vlida).
Cada uno de los casos de prueba puede ejercitar cualquier nmero de entradas vlidas
(cada fila puede contener ms de una entrada vlida).

-
La tabla resultante tendr las filas necesarias para que todas las clases vlidas y no
vlidas sean probadas al menos una vez.
Si nos presentan una tabla de este tipo pero sin la columna de clases ni la de caminos nos ser
imposible distinguir el mtodo por el cual se han diseado los casos de prueba.
JUnit automatiza esta tabla y no tienen en cuenta el mtodo usado para disear los casos de
prueba.
Reglas para obtener las particiones.
Se presentan algunas maneras de generar particiones que luego se tendrn que combinar para
casos ms complejos.
Adems podemos crear particiones con valores lmite para probar valores que estn cerca de
los lmites de las particiones.
Veremos ms casos y ejemplos en las prcticas.
89

Tema 5: Verificacin y Validacin
90

Este es el ltimo tema del curso, el tema 5, aunque lo vemos despus del 6 y el 7 porque en
prcticas convena seguir este orden.
En este tema se va a remarcar la importancia de las pruebas as como clasificarlas y hacer el
uso de stubs. Adems si nos dan un proyecto software tenemos que saber planificar las
pruebas e implementar stubs.
Pruebas. Principales Conceptos.

Las pruebas nos ayudan a conseguir el principal objetivo del gestor, el entregar el proyecto a
tiempo sin sobreexceder un coste y que entregue unas funcionalidades concretas. Las pruebas
nos ayudan a ver que las funcionalidades son las adecuadas.
Repetimos que lo primero que se deja de hacer cuando falta tiempo son las pruebas por lo que
buscamos ser eficientes y encontrar el mximo nmero de errores en el menor tiempo posible
con el menor nmero de casos de prueba.
Destacar tambin que durante el desarrollo, un 30-40% de las actividades estn relacionadas
con las pruebas.
Los objetivos de las pruebas, de la verificacin y validacin son descubrir defectos en el
sistema (descubrir cosas que no van bien) y evaluar si el sistema funciona segn las
expectativas del cliente (el cliente est contento con el programa?).
Estos dos trminos forman parte del proceso de prueba software (Verificacin y Validacin).
Recordamos de los otros temas que el proceso de prueba puede demostrar la presencia de
errores y nunca la ausencia de estos. Para ver que hay ausencia de errores tendramos que
hacer uso de pruebas exhaustivas que recorriesen todos los caminos del programa, pero son
impracticables. En el ejemplo hay 10^14 caminos. El coste temporal hara estas pruebas
impracticables con la tecnologa actual.
En cuanto a la verificacin:
-
Implica probar el programa implementado para ver si funciona conforme a las

especificaciones.
Tenemos que responder Estamos construyendo el programa CORRECTAMENTE?
Perseguimos detectar situaciones en las que el comportamiento del software es
incorrecto o no conforme a la especificacin.
Una prueba exitosa es aquella que demuestra que el programa funciona mal.
En cuanto a la validacin:
-
91
Implica probar el programa implementado para ver si satisface las necesidades del
cliente.
Se trata de responder: Estamos construyendo el programa correcto?
Buscamos que el programa funcione correctamente usando los casos de prueba que
reflejen el uso esperado del sistema.

-
Una prueba exitosa es aquella que muestra que el programa es el correcto.
El proceso de las pruebas ya lo vimos en el tema 7, pero aqu se vuelve a ver.

A partir de los mtodos que hemos aprendido debemos disear unos casos de prueba.
Posteriormente se preparan los datos y se ejecutan, podemos automatizar esta ejecucin con
herramientas como JUnit. Posteriormente se comparan los resultados obtenidos con los
esperados y se hace un informe de las pruebas.
El objetivo, de nuevo, es encontrar defectos en el software de la forma ms eficiente posible,

es decir, con el menor nmero de pruebas posible.
Esta es la manera de proceder al hacer las pruebas. Pero este proceso hay que repetirlo en tres
etapas generales durante el desarrollo de un software.
-
Pruebas de unidad o de componentes.

Prueba del sistema o verificacin.
Pruebas de aceptacin o validacin.
Adems de saber que es cada cosa y el proceso de las pruebas no hay que dejar pasar el
trmino depuracin y destacar que son procesos distintos, las pruebas y la depuracin.
El primero de ellos pone en evidencia la presencia de errores y el otro localiza y repara los
errores.
Normalmente, en proyectos grandes, estas actividades las realizan dos persos distintas pero en
proyectos relativamente pequeos lo puede hacer la misma persona cambiando de rol.
Planificacin de las pruebas.

Como todos los planes que hemos ido viendo a lo largo de la asignatura en este tambin
tenemos que responder QUE pruebas hacer, COMO hacerlas, QUIEN las tiene que hacer y
CUANDO deben hacerse.
Decir adems que todo esto puede verse influenciado por el modelo de proceso seguido como
veremos posteriormente.
92

Antes de nada vamos a responder el QUE, qu tipo de pruebas tenemos que hacer? Para ello
hay que conocer la clasificacin de las pruebas, vamos a ver varias de estas clasificaciones.
Segn la necesidad de ejecutar el cdigo para detectar defectos:
-
Dinmicas.
Estticas.
Segn los objetivos de las pruebas:

-
Pruebas de validacin (necesito al cliente).

o Alfa: Son aquellas en las que nos podemos reunir con el cliente. Una vez
reunidos hacemos que el cliente use el software y vamos tomando nota de sus
movimientos y los fallos detectados.
o Beta: Se lanza un nmero limitado de unidades al mercado o en Internet y
mediante un feedback por parte de los usuarios se detectan errores.
Pruebas de verificacin (defectos).
o Pruebas de particiones (Caja blanca).
o Pruebas de estructurales (Caja negra).
Segn el elemento al que se aplica:

-
Pruebas del sistema.

o Pruebas de integracin (regresin).
o Pruebas de aceptacin o de entregas.
o Pruebas de propiedades emergentes.
Pruebas de componentes.
o Pruebas de funciones o mtodos dentro de un objeto.
o Prueba de clases.
o Pruebas de componentes formados a partir de la composicin de varios
objetos (de Interfaces).
Especial mencin requieren las pruebas de integracin, implicando este proceso construir el
sistema a partir de sus componentes individuales y probar el (sub)sistema resultante para
detectar defectos en las interacciones entre dichos componentes.
Este tipo de pruebas suelen realizarse de forma incremental. Lo fundamental es el orden a
seguir a la hora de hacer la integracin disponiendo de dos modelos segn el orden de las
llamadas entre componentes.
93

Bottom-Up.
Los errores se localizan ms fcilmente que con big-bang (todo
de golpe) y no se necesitan stubs puesto que se primero se
integran los componentes que no hacen llamadas a otros
componentes.
Otra ventaja es que las pruebas pueden hacerse en conjuncin
con la implementacin.
Como inconveniente tiene que los mdulos de ms alto nivel se
prueban los ltimos y por lo tanto se prueban menos y no
disponemos de un esqueleto del sistema hasta el final por lo que
tendremos que usar algn driver.
Top-Down.
No hacen falta muchos drivers puesto que se hace de
arriba abajo integrando primero los componentes de ms
alto nivel por lo que harn falta bastantes stubs. Por otro
lado estos mdulos son los ms probados siendo los
menos los ms pequeos y potencialmente reutilizables.
Este mtodo no es aconsejable cuando no queremos que
sea muy costoso puesto que la creacin de stubs
consume bastante tiempo.
Hay otros modelos de integracin, por ejemplo el modelo sndwich mezcla los dos y va
integrando por arriba y por abajo. El modelo dirigido por los riesgos es usado por UP y da igual
el orden de llamada, se integra primero lo ms crtico.
Durante la integracin se hacen pruebas de regresin que consiste en una vez integrado un
componente se prueba todo lo que ya estaba integrado.
Proceso de planificacin.
Se trata de enlazar las actividades de pruebas y las de desarrollo buscando un equilibrio entre
las pruebas estticas y las dinmicas.
94

La imagen anterior muestra un enlace general entre el desarrollo y las pruebas. Bsicamente
viene a demostrar que las primeras pruebas diseadas son las que se prueban las ltimas. Ms
que nada por los requerimientos de las pruebas para ser diseadas.
Primero, a partir de la especificacin de los requerimientos y del sistema se puede hacer un
plan de aceptacin. A partir de la especificacin del sistema y del diseo de los componentes
se puede planificar las pruebas de integracin, por ejemplo elegir el orden de integracin
cuando dispongamos de los componentes.
A partir del diseo y de un diseo ms detallado se puede hacer un plan de integracin de los
subsistemas.
Una vez codificado el programa realizamos las pruebas en orden inverso, como ya tenemos
los componentes podemos hacer la integracin de los subsistemas, luego la del sistema y por
ltimo la de aceptacin.
A partir de este modelo general surgen otros dos llamados modelo en V y modelo en W, la
diferencia entre ellos es el momento en el que se planifican las pruebas.
Modelo en V.
En este modelo se empiezan a
disear las pruebas despus de
codificar el programa. De esta
manera tenemos como ventaja que
si han cambiado los requerimientos
durante la codificacin cuando
planifiquemos las pruebas del
sistema ya tendremos esos cambios
en cuenta. Como desventaja
tenemos que puede pasar mucho
tiempo desde las diferentes fases hasta que se disean y realizan las pruebas.
Modelo en W.
Este modelo se parece ms al
general, planificando las pruebas
justo despus de llevar a cabo las
fases del proyecto. Hay una gran
cercana en el tiempo entre la fase
y el diseo de las pruebas por lo
que suelen estar ms claras. Una
vez se codifica se pasan las pruebas
en orden inverso al diseo de estas
y se hace un debug cuando se encuentra algn error volviendo a ejecutar el tipo de pruebas
anterior.
95

Adems de estos modelos hemos estudiado las pruebas como disciplina de desarrollo en el
modelo UP hacindose estas a lo largo de todas las iteraciones y fases, desde el comienzo al
final de las fases. Eso s, en cada fase haremos un tipo de pruebas adecuado para lo que se est
haciendo. As, en las fases tempranas, a partir del modelado del sistema, podemos hacer
pruebas estticas y una vez vamos integrando componentes, antes de ello hacer pruebas de
unidad. Etc.
En el modelo XP, como vimos, se sigue una metodologa de desarrollo dirigida por las pruebas,
de esta manera primero se crea la prueba de unidad y se desarrolla el cdigo necesario para
pasar estas pruebas. Si falla la prueba puede simplificarse el cdigo o cambiar de parejas para
detectar los errores. Se sigue programando entonces para satisfacer la prueba. Adems se va
haciendo una integracin constante probando el 100% de las pruebas de unidad al sistema.
96

Uso de Stubs.
Como vimos en el tema 6 con JUnit se pueden automatizar las pruebas pero haba un
problema cuando el mtodo a probar llamaba a mtodos u objetos no implementados. Para
eso se usan los Stubs, para sustituir el cdigo de esas llamadas.
Partimos de que est TOTALMENTE PROHIBIDO modificar la clase a probar.
Los stubs, como se deca, son implementaciones ficticias de aquellos mtodos a los que invoca
el componente a probar.
Los stubs proporcionan respuestas predefinidas para las unidades a probar, de forma que se
pueden hacer aserciones sobre la forma en que dicha unidad reacciona ante dichas respuestas.
Se hace una verificacin de los resultados obtenidos basada en el ESTADO, es decir, se
comprueba que la unidad funciona correctamente examinando el resultado de la ejecucin de
dicha unidad. No importa lo que pase dentro del metodoB, sino lo que devuelve y como se
comporta la UP con ese valor de vuelta.
Ejemplo de Stub:
Queremos probar un mtodo que representa un pedido a un almacn, concretamente se trata
de Order.fill(warehouse). Si hay suficientes unidades del producto en el almacn el pedido es
procesado y se descuentan las unidades del producto correspondiente en el almacn. Si no hay
suficientes, no se procesa.
97

Existen tambin los Mocks, aunque no los vamos a usar siempre es bueno saber que pinta
tienen. La diferencia fundamental con los Stubs es que se realiza una verificacin de la
correccin basada en el comportamiento, lo que significa que se comprueba si el Mock realiza
las llamadas en el orden correcto.
Los stubs son buenos usarlos porque pueden simular el comportamiento de objetos complejos
y por lo tanto, resultan tiles cuando no es prctico o resulta imposible incorporar objetos
reales en dicha unidad de prueba.
Es conveniente usarlos cuando el objeto real:
-
Proporciona resultados no deterministas.

Contiene estados difciles de crear o reproducir.
Es lento (base de datos compleja).
No existe o puede cambiar su comportamiento.
Puede tener que incluir mtodos solo para las pruebas.
Los stubs se pueden implementar de dos maneras.

Mediante Interfaces.
Suponemos que tenemos una clase que gestiona unos pedidos. El mtodo recibirPedido enva
un email cuando completa la recepcin de un pedido.
98
Refactorizamos el cdigo real de la clase a probar de la siguiente manera.
La distribucin de cdigo quedara algo as.
Y luego a la hora de probar con JUnit.
99
Mediante Herencia.
Tenemos una clase que procesa pedidos. El mtodo process calcula y aplica un descuento
sobre el pedido. El descuento se obtiene consultando el servicio PricingService que no
tenemos implementado.
100
101

Ejercicio planteado en clase del examen de Diciembre 2009.
Dada esa clase, implementar con JUnit las pruebas para recorrer todos los caminos del mtodo
calculaConsumo. Indicar todo el cdigo necesario para automatizar las pruebas. Asumir que
DIURNA y NOCTURNA son dos valores globales.
Yo asignar a DIURNA 5cents y a NOCTURNA 2cents.
Heredo de la clase a probar para sobreescribir el mtodo getHoraActual ya que usa una
llamada al sistema, lo sobrescribo para lo que yo quiero.
102

Ahora con JUnit implementamos las pruebas sobre esta nueva clase.
103

Pruebas de Sistemas Software

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Pruebas de Sistemas Software

Загружено:

Авторское право:

Доступные форматы

Aprobando Ingeniera

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Anlisis y definicin de requerimientos: Los servicios, restricciones, y las metas del

El coste de subsanar omisiones o cambios en los requerimientos as como arreglar

Aprobando Ingeniera del Software II 2010

Disponemos de dos tipos de modelos evolutivos:

Desarrollo explorativo: se trabaja con el cliente para explorar sus requerimientos y

Aprobando Ingeniera del Software II 2010

Las etapas de especificacin de requerimientos y validacin son comparables a las de otros

Anlisis de componentes: Una vez obtenida la especificacin se buscan los

De nuevo, ventajas e inconvenientes.

Reduce la cantidad de software a desarrollar, reduciendo costes y riesgos.

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Determinar objetivos, alternativas y restricciones: Se definen los objetivos especficos

Se centran en el cdigo en vez de en el diseo.

Usados normalmente para sistemas de empresas pequeas o medianas.

Aprobando Ingeniera del Software II 2010

Desarrollo incremental: Llevado a cabo mediante entregas pequeas del sistema

Aprobando Ingeniera del Software II 2010

Dinmica: Muestra las fases a lo largo del tiempo.

Perspectiva dinmica. Fases.

Aprobando Ingeniera del Software II 2010

Desarrollo iterativo: Planificar incrementos con la prioridad de los mismos para el

Se vers mas de RUP en el material adicional y en las prcticas del tema.

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Si estamos con la duracin fija y la actividad es condicionada por el esfuerzo, la asignacin de

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Introducir datos reales: HerramientasSeguimientoActualizar tareas. Con esto los

Fechas de inicio y fin.

Un ejemplo de estos tres parmetros se puede encontrar en las transparencias 42, 43 y 44

Si BAC = BCWS: La tarea debera haber acabado ya.

Veamos ahora el funcionamiento de EVA.

Schedule Variance (SV) = BCWP BCWS.

Aprobando Ingeniera del Software II 2010

Schedule Performance Index (SPI) = BCWP / BCWS.

Cost Variance (CV) = BCWP ACWP.

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Igual que en el ejercicio anterior pero dejando la duracin fija.

Qu pasa si A se retrasa 3 das? No pasa nada, el proyecto no se retrasa y B puede comenzar

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Aprobando Ingeniera del Software II 2010

Estimacin y planificacin. Importancia de las estimaciones. Errores al estimar.

Aprobando Ingeniera del Software II 2010

Mejoran la visibilidad del estado del proyecto: Si la agenda planificada es realista

Informacin inexacta: No disponemos de suficiente informacin sobre lo que tenemos

Cono de la incertidumbre y los valores de las estimaciones.

Aprobando Ingeniera del Software II 2010

En el eje x se tiene el nivel de detalle considerado a la hora de presupuestar, o mejor

Budgeting effort: Cuanta ms informacin se disponga ms esfuerzo costar hacer una