Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Tecnicas de Evaluacion de Software
Tecnicas de Evaluacion de Software
Versin: 12.0
Fecha: 17 de octubre de 2006
Autoras: Natalia Juristo, Ana M. Moreno, Sira Vegas
TABLA DE CONTENIDO
1.
2.
3.
4.
3.4.4.1
3.4.4.2
3.4.4.3
3.4.4.4
PARTICIONES DE EQUIVALENCIA......................................................................................................................... 40
4.2.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
5.
6.
Pg. 2
ANEXO F.
84
ANEXO J.
N.Juristo/A. Moreno
Pg. 3
Por otra parte, la comprobacin que emprica no sirve para garantizar que no hay errores en el
software, puesto que ello depende, por un lado, de la porcin del programa que se est
ejecutando en el momento de esta comprobacin, y por otro, de las entradas que se le hayan
proporcionado al cdigo. Por lo tanto, pueden existir errores en otras partes del programa que
no se ejecuten en ese momento o con otras entradas que no se hayan usado en la prueba.
Por lo tanto, lo recomendable es que producto software vaya siendo evaluado a medida que se va
construyendo. Como veremos posteriormente, se hace necesario llevar cabo, en paralelo al proceso de
desarrollo, un proceso de evaluacin o comprobacin de los distintos productos o modelos que se van
generando, en el que participarn desarrolladores y clientes.
W. Wayt Gibbs. Softwares Chronic Crisis. Scientific American. Number 218. November 1994.
N.Juristo/A. Moreno
Pg. 4
No obstante, la calidad que se puede obtener mediante este procedimiento artesanal es bastante baja.
De ah que, a pesar de haber sido ensayados rigurosa y sistemticamente, la mayora de los programas
grandes contengan todava defectos cuando son entregados. Ello se debe a la complejidad del
software. Un programa de apenas unos centenares de lneas de cdigo puede contener decenas de
decisiones, lo que permite millares de rutas de ejecucin alternativas, resultando materialmente
imposible el ensayo exhaustivo de todas las posibles rutas alternativas. Para alcanzar una confianza de
no ms de 10-9 fallos por hora tendra que ejecutarse un programa durante muchsimos mltiplos de
109 horas, esto es, durante muchos mltiplos de 100.000 aos2.
As pues, la ambicin de conseguir programas perfectos sigue siendo una cima inaccesible. Existe, hoy
por hoy, la imposibilidad prctica de conseguir software totalmente libre de defectos2 y, debemos, por
tanto, aceptar las actuales limitaciones que padece la construccin de sistemas software. De hecho,
algunos autores3 sugieren que, dada la entidad no fsica del software, los defectos en los programas
son inherentes a su naturaleza.
Es difcil establecer cul es la cantidad media de defectos que un sistema software normal contiene.
Hay estimaciones, como la del Software Engineering Institute4, que dicen que un programador experto
introduce un defecto por cada 10 lneas de cdigo; suponiendo que se detectasen el 99% de los
defectos introducidos (lo cual resulta tremendamente optimista) an permaneceran 1 defecto por cada
1.000 lneas de cdigo (KLOC5).
No obstante, la depuracin de los sistemas software obedece a la ley del rendimiento decreciente. Esto
es, segn se avanza en el proceso de bsqueda de defectos, el coste de deteccin de fallos y
eliminacin de las faltas que los provocan empieza a rebasar con mucho las mejoras conseguidas en la
fiabilidad del sistema. Ntese que la fiabilidad de un software no se mide como la cantidad de faltas
que quedan en un programa, sino como el tiempo medio entre fallos6. As pues, el objetivo de las
tcnicas de evaluacin del software no es tanto la eliminacin total de las faltas existentes en los
programas, como la eliminacin de las faltas que provocan fallos frecuentes. Si se persevera durante
muchsimo tiempo en la depuracin de un software, acabamos descubriendo faltas que producirn
fallos tan infrecuentes que su enmienda no incide en la fiabilidad percibida del sistema.
De hecho, hasta el software ms depurado y considerado de alta fiabilidad contiene defectos
remanentes. Edward N. Adams de IBM analiz empricamente7 los tamaos de las faltas en una base
de datos de cobertura mundial que supona el equivalente de miles de aos de uso de un sistema
informtico particular. El descubrimiento ms extraordinario consisti en que alrededor de la tercera
parte de las faltas contenidas en un programa son quinquemilenarias. Esto es, faltas que produciran un
fallo tan slo una vez cada 5.000 aos. Estas faltas excepcionales sumaban una porcin considerable
del total de faltas remanentes, pues las faltas responsables de de fallos ms frecuentes haban sido
descubiertas y consiguientemente eliminadas durante la fase de evaluacin y en los primeros meses de
operacin del sistema. Obviamente, emplear tiempo en detectar faltas que producen fallos cada ms
all de 75 aos es malgastar recursos.
2
Bev Littlewood and Lorenzo Strigini. The Risks of Software. Scientific American. Volume 268, Number 1,
January, 1993
Y. Huang, P. Jalote and C. Kintala. Two Techniques for Transient Software Error Recovery. Lecture Notes in
Computer Science, Vol. 774, pages 159-170. Springer Verlag, Berlin, 1994.
KLOC es el acrnimo ingls de Kilo Lines Of Code, esto es, 1.000 lneas de cdigo.
Una falta en el cdigo es la causante de un fallo en el funcionamiento del sistema. Los fallos se perciben como
errores por los usuarios del sistema. Las faltas, mientras no se manifiestan como fallo durante el
funcionamiento del sistema, no pueden ser apreciadas por los usuarios. El trmino defecto se utiliza cuando no
es necesario la exactitud de diferencias entre falta y fallo.
E. Adams. Optimizing Preventive Service of Software Products. IBM Research J., vol. 28, no. 1, pages. 2-14,
1984.
N.Juristo/A. Moreno
Pg. 5
Si hablamos de valores reales, en lugar de estimaciones, unos buenos ejemplos de cuntos fallos son
normales en un software pueden serlo los sistemas operativos. La tasa de defectos de Linux es 0,1
defectos/KLOC8. Las distintas versiones de Unix tienen entorno a 0,6-0,7 defectos/KLOC4. Los
sistemas operativos con interfaz grfico como Windows 95 o MacOS posean una tasa de
defectos/KLOC tan elevada que fallaban cada tres horas, o incluso menos, de funcionamiento
ininterrumpido9. Otro ejemplo, Siemens sufri una tasa de 6-15 defectos /KLOC en el desarrollo de
alguno de sus sistemas operativos10.
Fuera del mbito de los sistemas operativos existen pocas, aunque elocuentes, referencias a las tasas
de defectos del software. As, Unisys alcanz una tasa de 2-9 defectos/KLOC en el desarrollo de
software de comunicaciones. IBM, en el desarrollo normal de software, puede llegar a sufrir una tasa
de 30 defectos/KLOC. Como se ve la variabilidad entre unos casos y otros es muy alta, lo que impide
sacar reglas sobre qu es normal
Incluso utilizado tcnicas muy avanzadas (las que se usan en sistemas de alto riesgo como la conocida
Cleanroom Development11) es imposible lograr un software totalmente libre de defectos. As, por
ejemplo, la misma IBM no consigui rebajar su tasa de defectos de 2,3-3,4 defectos/KLOC utilizando
la tcnica Cleanroom12.
La UK Civil Aviation obtuvo una tasa de defectos de 0,81 / KLOC en el desarrollo del sistema de
control de trfico areo del Reino Unido. Ntese que, en este caso, la necesidad de fiabilidad y
robustez del sistema es enorme y, sin embargo, casi se alcanz 1 defecto/KLOC, lo que parece indicar
que 1 puede considerarse el lmite inferior de la tasa de defectos alcanzable. Sin embargo, en otros
casos de sistemas software tambin crticos y que requieren programas especialmente fiables, se ha
superado con creces este lmite. As, segn los datos publicados hasta la fecha, la NASA13 ha sufrido
tasas de defectos en el rango 4-12 defectos /KLOC.
Cabe preguntarse, en consecuencia, qu tasa de defectos debe considerarse normal en un proyecto de
desarrollo. Existen autores que afirman que es habitual encontrar en el software comercial entre 25-30
defectos/KLOC14. No obstante, aplicando una visin exigente tenemos que:
16-19
June,
1997.
http://guinness.cs.stevens-
10
L. Hatton. Programming Languages and Safety-Related Systems. Proc. Safety-Critical Systems Symp.,
Springer-Verlag, New York, 1995, pp. 48-64, citado en S. L. Pfleeger and L. Hatton. Investigating the
Influence of Formal Methods. IEEE Computer, Volume 30, Issue 2 (February 1997), pp. 33-43.
11
R. C. Linger. Cleanroom Process Model. IEEE Software, Volume 11, issue 2 (March 1994), pp 50-58.
12
Cleanroom Development es una de las ms depuradas, avanzadas y contrastada para desarrollar sistemas
software con baja tasa de defectos. La razn de su no amplia utilizacin es su altsimo coste, que hace
dispararse los costos de los proyectos. As pues, nicamente se aplica cuando el cliente lo exige y acepta el
aumento que produce en el precio del desarrollo.
13
La NASA es considerado uno de los centros de desarrollo de software ms avanzado a nivel mundial. Durante
aos sus investigaciones en el Software Engineering Laboratory, en Maryland EE.UU, han marcado
tendencias en la construccin de software. La razn para esto es clara: los fallos en los vehculos de la NASA
son irreversibles, pues no hay opcin para que un desarrollador se acerque al sistema y resuelva el problema.
En otras palabras, no puede permitirse el lujo de tener fallos.
14
M. Dyer. The Cleanroom Approach to Software Quality. John Wiley & Sons, New York, 1992.
N.Juristo/A. Moreno
Pg. 6
Puede considerarse que un software posee alta calidad cuando su tasa de defectos es menor de
15 defectos/KLOC.
Eficiencia Habilidad del software para responder a una peticin de usuario con la
velocidad apropiada.
A su vez, cada una de estas caractersticas del software puede subdividirse en atributos an ms
concretos. La Tabla 1 muestra una posible subdivisin. Aunque existen muchas otras
descomposiciones de la calidad del software, sta es una de las ms aceptadas.
N.Juristo/A. Moreno
Pg. 7
CHARACTERISTICS AND
SUBCHARACTERISTICS
Functionality
Suitability
Accuracy
Interoperability
Security
Compliance
Reliability
Maturity
Fault tolerance
Recoverabiltiy
Compliance
Usability
Understandability
Learnability
Operability
Attractiveness
Compliance
Efficiency
Time behavior
Resource utilization
Compliance
Maintainability
Analyzability
Changeability
Stability
Testability
Compliance
Portability
Adaptability
Installability
Co-existence
Replaceability
Compliance
DESCRIPTION
Characteristics relating to achievement of the basic purpose for which the software is being engineered
The presence and appropriateness of a set of functions for specified tasks
The provision of right or agreed results or effects
Softwares ability to interact with specified systems
Ability to prevent unauthorized access, whether accidental or deliberate, to programs and data
Adherence to application-related standards, conventions, regulations in laws and protocols.
Characteristics relating to capability of software to maintain its level of performance under stated conditions for a stated period of time
Attributes of software that bear on the frequency of failure by faults in software
Ability to maintain a specified level of performance in cases of software faults or unexpected inputs
Capability and effort needed to re-establish level of performance and recover affected data after possible failure
Adherence to application-related standards, conventions, regulations in laws and protocols
Characteristics relating to the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users
The effort required for a user to recognize the logical concept and its applicability
The effort required for a user to learn its application, operation, input and output
The ease of operation and control by users
The capability of the software to be attractive to the user
Adherence to application-related standards, conventions, regulations in laws and protocols
Characteristics related to the relationship between the level of performance of the software and the amount of resources used, under stated conditions
The speed of response and processing times and throughput rates in performing its function
The amount of resources used and the duration of such use in performing its function
Adherence to application-related standards, conventions, regulations in laws and protocols
Characteristics related to the effort needed to make modifications, including corrections, improvements or adaptation of software to changes in
environment, requirements and functional specifications
The effort needed for diagnosis of deficiencies or causes of failures, or for identification parts to be modified
The effort needed for modification fault removal or for environmental change
The risk of unexpected effect of modifications
The effort needed for validating the modified software
Adherence to application-related standards, conventions, regulations in laws and protocols
Characteristics related to the ability to transfer the software from one organization or hardware or software environment to naother
The opportunity for its adaptation to different specified environments
The effort needed to install the software in a specified environment
The capability of a software product to co-exist with other independent software in common environment
The opportunity and effort of using it in the place of other software in a particular environment
Adherence to application-related standards, conventions, regulations in laws and protocols
N.Juristo/A. Moreno
Pg. 8
Verificacin: Proceso de determinar si los productos de una cierta fase del desarrollo de
software cumplen o no los requisitos establecidos durante la fase anterior.
Validacin: Proceso de evaluacin del software al final del proceso de desarrollo para
asegurar el cumplimiento de las necesidades del cliente.
N.Juristo/A. Moreno
Pg.9
Nuestro objetivo es conseguir que las tres visiones coincidan. A la interseccin entre la calidad
Requerida y la calidad Realizada se le llama calidad Percibida, y es la nica que el cliente valora.
Toda aquella calidad que se realiza pero no se necesita es un gasto intil de tiempo y dinero.
Tanto para la realizacin de verificaciones como de validaciones se pueden utilizar distintos tipos
de tcnicas. En general, estas tcnicas se agrupan en dos categoras:
Tcnicas de Evaluacin Estticas: Buscan faltas sobre el sistema en reposo. Esto es,
estudian los distintos modelos que componen el sistema software buscando posibles faltas
en los mismos. As pues, estas tcnicas se pueden aplicar, tanto a requisitos como a
modelos de anlisis, diseo y cdigo.
Veamos en la siguiente seccin cmo estas tcnicas de evaluacin han de aplicarse durante todo el
proceso de desarrollo. Pero antes recordemos que todo proceso de evaluacin adems de la posible
deteccin de defectos conlleva un proceso de depuracin, esto es la correccin de los mismos.
Ambas tareas (deteccin y correccin) pueden realizarse por una misma persona o por personas
distintas segn la organizacin y el modelo de desarrollo sobre el que se est aplicando la tcnica.
Las tcnicas de evaluacin, tanto las estticas como las dinmicas, no aportan ayuda en la
correccin de los defectos encontrados.
Bien es cierto, que en el caso de las tcnicas estticas, dado que detectan faltas su correccin es ms
directa. Mientras que las tcnicas dinmicas, como se centran en los fallos su proceso de depuracin
asociado es mucho ms complejo, puesto que se debe, primero, buscar la falta que provoca el fallo
(lo cual, no es en absoluto inmediato como sabe cualquier programador) y posteriormente
corregirlo.
N.Juristo/A. Moreno
Pg.10
m ic
in
Ev
alu
aci
n
D
are
ftw
So
de
ica
ll o
t t
rro
Es
sa
De
in
ac
a lu
Ev
Necesidad del
Usuario
Codificacin
N.Juristo/A. Moreno
Pg.11
Necesidad del
Usuario
Cdigo
Aceptado
Revisin de
Requisitos de
Usuario
Requisitos del
Usuario
Definicin de
Requisitos de
Usuario
Pruebas de
Aceptacin
Cdigo instalado
en hw de usuario y
probado
Requisitos del
Usuario
Revisados
Definicin de
Requisitos
Software
Requisitos del
Software
Revisin de
Requisitos de
Software
Pruebas de
Sistema
Cdigo con la
interaccin entre
mdulos probada
Requisitos del
Software
Revisados
Pruebas de
Integracin
Diseo de la
Arquitectura
Diseo
Arquitectinico
Revisin del
Diseo
Arquitectnico
Diseo
Arquitectinico
Revisado
Revisin del
Diseo
Detallado
Diseo
Detallado
Pruebas de
Unidad
Diseo
Detallado
Cdigo
Revisado
Diseo
Detallado
Revisado
Codificacin
Cdigo
Revisin del
Cdigo
Cdigo
Revisado
En otras palabras, las actividades de revisin acompaan las actividades del modelo de desarrollo
de software que gua el proyecto. En los modelos de desarrollo de software tradicionales, las
actividades de evaluacin tanto estticas como dinmicas tienen una inmersin clara dentro de cada
una de las fases del proceso. Es decir, se puede diferenciar claramente donde se introducen las
actividades de revisin pues cada fase de desarrollo est claramente diferenciada. En modelos de
proceso de software recientes como es el caso de los Modelos de Proceso giles y particularmente
en XP, no sucede claramente de la misma manera. La necesidad de hacer liberaciones de cdigo a
intervalos cortos de tiempo (totalmente probadas) permite involucrar la evaluacin en cada una de
las actividades diarias que acompaan el proceso de desarrollo. Las pruebas de aceptacin, por
ejemplo son pruebas definidas por el cliente con ayuda de un miembro del equipo de desarrollo bajo
el rol de Tester o Verificador. Estas buscan medir la funcionalidad de la caracterstica seleccionada
por el cliente para ser implementada en esa liberacin. Las pruebas se establecen como fundamento
del desarrollo, del control de cambios y del trabajo conjunto del cliente con el desarrollador a travs
de todo el proceso de desarrollo.
N.Juristo/A. Moreno
Pg.12
En general y por tanto, las actividades de evaluacin esttica constituyen los puntos de control o
revisin utilizados por los gestores de proyectos y las organizaciones para evaluar tanto la calidad
de los productos como el progreso del proyecto. Es decir, las actividades de revisin son una
herramienta de control para el producto software.
Una vez realizadas estas revisiones se procede con la evaluacin dinmica, que como ya se ha
indicado se realiza sobre el cdigo. Aunque ms adelante se estudiarn en detalle los distintos tipos
de pruebas dinmicas, se puede indicar que la primera prueba a realizar es la denominada Prueba de
Unidad en la que se buscan errores en los componentes ms pequeos del programa (mdulos).
Estos errores se detectan cuando dichos componentes no actan como se ha especificado en el
diseo detallado.
En el caso de XP, a consecuencia de la refactorizacin, es necesario correr una sesin de pruebas
para verificar que, los cambios no han afectado el comportamiento del sistema, es decir, que no han
introducido defectos. En la Programacin por Pares (uno de los principios de XP), todo el cdigo
debe escribirse por pares de programadores. En forma conjunta, dos personas escriben cdigo
sentados frente a un ordenador, turnndose en el uso del ratn y el teclado. Mientras uno piensa
desde un punto de vista ms estratgico y realiza lo que podra llamarse cdigo en tiempo real, el
otro programador escribe directamente el cdigo, alternndose en los roles varias veces al da. Las
Pruebas de Unidad son escritas por cada par de programadores cuando se escribe el cdigo. Las
pruebas se ejecutan bajo un proceso de integracin y construccin continua que brinda una
plataforma estable para el desarrollo.
Seguidamente, se prueban los distintos componentes que constituyen el software en la denominada
Prueba de Integracin. Esta prueba est orientada a detectar fallos provocados por una incorrecta
(no acorde con la especificacin de diseo de alto nivel) comunicacin entre mdulos. El software
se puede ejecutar en un contexto hardware concreto, por lo que la Prueba de Sistema es la que se
encarga de buscar errores en este ensamblaje sofware/hardware. Finalmente, el usuario ha de
realizar la Prueba de Aceptacin final sobre el sistema completo.
Para XP, el principio de Pruebas de Cliente, consiste en que el cliente define una o ms pruebas
de aceptacin. Estas pruebas se automatizan para mostrar que la caracterstica que el cliente desea
est funcionando correctamente. El equipo construye esas pruebas y las usa para probarse as
mismos y para mostrarle al cliente que la caracterstica ha sido implementada correctamente. La
automatizacin de las pruebas es importante puesto que para XP, la liberacin de cdigo en cortos
plazos de tiempo es indispensable. Por ello, las pruebas estticas al cdigo no vendran siendo la
mejor opcin.
Ntese cmo la evaluacin de los productos software mediante revisiones permite contar con una
estimacin temprana de la calidad con que se est llevando a cabo el desarrollo. Esto es as porque
las revisiones encuentran faltas, pero la cantidad de faltas encontradas en un producto dan una idea
de las faltas que an pueden quedar as como de la calidad del trabajo de desarrollo de dicho
producto. La experiencia parece indicar que donde hay un defecto hay otros. Es decir, la
probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de
defectos ya descubiertos. Es en este principio sobre el que se basan los mtodos de estimacin de
los defectos que quedan en un software; ya sean los modelos de fiabilidad (que utilizan como
entrada los fallos encontrados durante las pruebas) ya sean los mtodos de estimacin del contenido
de faltas (que utilizan como entrada las faltas encontradas mediante revisiones). No obstante, es
gracias a la evaluacin esttica que se puede realizar esta estimacin de la calidad del software de
manera temprana, puesto que los modelos de fiabilidad requieren el cdigo ya desarrollado para dar
una indicacin de los posibles fallos que quedan remanentes en dicho cdigo.
N.Juristo/A. Moreno
Pg.13
Seguir revisando el producto para disminuir el nmero de faltas remanentes. Por tanto
esta deteccin temprana previene encontrar estas faltas en estadios ms avanzados del
desarrollo. Es decir, la falta que detectemos en los requisitos estaremos evitando
contagiarla al diseo y al cdigo.
Tomar medidas correctivas del desarrollo si las estimaciones indican que se est
llevando a cabo un trabajo pobre. Es decir, si las estimaciones de faltas remanentes
indican que un determinado producto contiene ms faltas de las habituales, algo se est
haciendo mal (hay problemas en el equipo de desarrollo, algn miembro del equipo
tiene problemas que est afectando a su trabajo, hay problemas con las tcnicas que se
estn utilizando, quizs el equipo no las conoce bien, etc.) y deben tomarse acciones
que remedien o palien estos problemas antes de que afecten al resultad final del
proyecto.
N.Juristo/A. Moreno
Pg.14
N.Juristo/A. Moreno
Pg.15
Para el diseo:
N.Juristo/A. Moreno
Pg.16
Complecin. El diseo debe estar completo. Ya sea que disea todo el sistema
marcado por los requisitos; ya sea no diseando ninguna parte no indicada en
los requisitos. De nuevo, nada falta, nada sobra.
Cdigo Fuente:
o Correccin. El cdigo no debe contener errores. Los errores de correccin se
pueden referir a dos aspectos. Defectos de escritura, es decir, lo que
habitualmente se conoce por programa que no funciona. Por ejemplo, bucles
infinitos, variable definida de un tipo pero utilizada de otro, contador que se
sale de las dimensiones de un array, etc. Defectos con respecto al diseo: el
diseo no realiza lo que el diseo establece.
De nuevo, hablando apropiadamente, los primeros son los puros defectos de correccin,
mientras que los segundos son defectos de validez. Un defecto de correccin es un cdigo
que est mal para cualquier dominio. Un defecto de validez es un cdigo que, en este
dominio particular (el marcado por esta necesidad de usuario, estos requisitos, y este
diseo) hace algo inapropiado. Por ejemplo, define una variable de un tipo (y se usa en el
programa con ese tipo, es decir, a primera vista no hay nada incorrecto en la definicin
del tipo y su uso) que no es la que corresponde con el problema; o define un array de un
tamao que no es el que se corresponde con el problema. Ntese que para detectar los
errores de validez (en cualquier producto) debe entenderse el problema que se pretende
resolver, mientras que los defectos de correccin son errores siempre, an sin conocer el
problema que se pretende resolver.
o
Complecin. El cdigo debe estar completo. Una vez ms, nada falta ni nada
sobra (con respecto, en este caso, al diseo)
.
o
N.Juristo/A. Moreno
Pg.17
Auditorias. Las auditorias contrastan los artefactos generados durante el desarrollo con
estndares, generales o de la organizacin. Tpicamente pretenden comprobar formatos
de documentos, inclusin de toda la informacin necesaria, etc. Es decir, no se tratan
de comprobaciones tcnicas, sino de gestin o administracin del proyecto.
3.4 INSPECCIONES
3.4.1 QU SON LAS INSPECCIONES?
Las inspecciones de software son un mtodo de anlisis esttico para verificar y validar un producto
software manualmente. Los trminos Inspecciones y Revisiones se emplean a menudo como
sinnimos. Sin embargo, como ya se ha visto, este uso intercambiable no es correcto.
Las Inspecciones son un proceso bien definido y disciplinado donde un equipo de personas
cualificadas analiza un producto software usando una tcnica de lectura con el propsito de detectar
defectos. El objetivo principal de una inspeccin es detectar faltas antes de que la fase de prueba
comience. Cualquier desviacin de una propiedad de calidad predefinida es considerada un defecto.
N.Juristo/A. Moreno
Pg.18
Para aprender a realizar inspecciones vamos a estudiar primero el proceso que debe seguirse y luego
las tcnicas de lectura.
N.Juristo/A. Moreno
Pg.19
inspeccin, aunque luego juegue adems otros papeles. Los papeles que existen en una inspeccin
son:
Recolector. El recolector recoge los defectos encontrados por los inspectores en caso
de no haber una reunin de inspeccin.
Es necesario hacer ciertas consideraciones sobre el nmero de participantes. Un equipo de
inspeccin nunca debera contar con ms de cinco miembros. Por otro lado, el nmero mnimo de
participantes son dos: el autor (que acta tambin de inspector) y un inspector. Lo recomendable es
comenzar con un equipo de tres o cuatro personas: el autor, uno o dos inspectores y el moderador
(que acta tambin como lector y escriba). Tras unas cuantas inspecciones la organizacin puede
experimentar incorporando un inspector ms al grupo y evaluar si resulta rentable en trminos de
defectos encontrados.
Sobre el tema de cmo seleccionar las personas adecuadas para una inspeccin, los candidatos
principales para actuar como inspectores es el personal involucrado en el desarrollo del producto.
Se pueden incorporar inspectores externos si poseen algn tipo de experiencia especfica que
enriquezca la inspeccin. Los inspectores deben tener un alto grado de experiencia y conocimiento.
La fase de Lanzamiento consiste en una primera reunin donde el autor explica el producto a
inspeccionar a los otros participantes. El objetivo principal de esta reunin de lanzamiento, es
facilitar la comprensin e inspeccin a los participantes. No obstante, este meeting no es
N.Juristo/A. Moreno
Pg.20
N.Juristo/A. Moreno
Pg.21
Encontrar muchas faltas es sospechoso. Muchas faltas detectadas hacen pensar que
debe haber muchas ms, puesto que la creencia de que queden pocas faltas slo se
puede apoyar en la confianza en el proceso de inspeccin y no en la calidad del
artefacto (que parece bastante baja puesto que hemos encontrado muchas faltas)
Encontrar muy pocas faltas tambin resulta sospechoso, especialmente si es la primera
vez que se inspecciona este artefacto. Pocas faltas hacen pensar que deben quedar
muchas ms, puesto que esta situacin hace dudar sobre la calidad del proceso de
inspeccin: No puede saberse si se han encontrado pocas debido a la alta calidad del
artefacto o a la baja calidad de la inspeccin.
La estimacin ms fiable sobre el nmero de faltas remanentes que se puede obtener en una
Inspeccin es la coincidencia de faltas entre los distintos inspectores. Los mtodos que explotan
coincidencias para estimar se llaman Estimaciones Captura-Recaptura y no son originarias de la
Ingeniera del Software. En concreto lo us por primera vez Laplace para estimar la poblacin de
Francia en 1786, y se utilizan a menudo en Biologa para estimar el tamao de poblaciones de
animales. En el caso de las Inspecciones, el nivel de coincidencia de las faltas detectadas por los
distintos revisores es usado como estimador15.
La idea sobre la que se basa el uso de las coincidencias es la siguiente: Pocas coincidencias entre los
revisores, significa un nmero alto de faltas remanentes; Muchas coincidencias, significar pocas
faltas remanentes. Los casos extremos son los siguientes. Supongamos que todos los revisores han
encontrado exactamente el mismo conjunto de faltas. Esto debe significar que deben quedar muy
pocas faltas, puesto que el proceso de inspeccin parece haber sido bueno (los inspectores han
encontrado las mismas faltas) parece poco probable que queden ms faltas por ah que ningn
revisor ha encontrado. Supongamos ahora que ningn revisor ha encontrado las mismas faltas que
otro revisor. Esto debe querer decir que quedan muchas ms por encontrar, puesto que el proceso de
revisin parece haber sido pobre (a cada revisor se le han quedado ocultas n faltas todas las
encontradas por los otros revisores-) vaya usted a saber cuntas faltas ms han quedado ocultas a
todos los revisores. Esta situacin debera implicar una nueva inspeccin del artefacto (tanto para
mejorar la calidad del mismo, como para hacer un intento de mejorar la propia inspeccin).
15
Un estimador en una frmula usada para predecir el nmero de faltas que quedan. Un modelo de estimacin
es el paraguas para denominar a un conjunto de estimadores basados en los mismos prerrequisitos.
N.Juristo/A. Moreno
Pg.22
N.Juristo/A. Moreno
Pg.23
Al igual que la evaluacin de requisitos, la evaluacin de diseo es crucial, ya que los defectos de
diseo que queden y sean transmitidos al cdigo, cuando sean detectados en fases ms avanzadas
del desarrollo, o incluso durante el uso, implicar un rediseo del sistema, con la subsiguiente recodificacin. Es decir, existir una prdida real de trabajo.
Veamos un ejemplo de preguntas para el diseo:
Cubre el diseo todos los requisitos funcionales?
Resulta ambigua la documentacin del diseo?
Se ha aplicado la notacin de diseo correctamente?
Se han definido correctamente las interfaces entre elementos del diseo?
Es el diseo suficientemente detallado como para que sea posible
implementarlo en el lenguaje de programacin elegido?
En el Anexo B aparecen listas de comprobacin para diferentes productos del desarrollo
proporcionadas por la empresa Construx. Intenta revisar ahora de nuevo los requisitos del Anexo A,
esta vez usando las listas de comprobacin del Anexo B. Esta misma especificacin de requisitos se
N.Juristo/A. Moreno
Pg.24
usa ms tarde con otra tcnica de lectura. Ser entonces cuando aportemos la solucin sobre qu
defectos contienen estos requisitos.
Interfaces Externas:
Se declaran los ficheros con todos sus atributos de forma correcta?
Se abren todos los ficheros antes de usarlos?
Coincide el formato del fichero con el formato especificado en la lectura?Se
manejan correctamente las condiciones de fin de fichero? Se los libera de
memoria?
Se manejan correctamente los errores de entrada/salida?
Datos:
o Referencias de datos. Se refieren a los accesos que se realizan a los mismos.
Ejemplos tpicos son:
Utilizar variables no inicializadas
Salirse del lmite de las matrices y vectores
Superar el lmite de tamao de una cadena
o Declaracin de datos. El propsito es comprobar que todas las definiciones de los
datos locales son correctas. Por ejemplo:
Comprobar que no hay dos variables con el mismo nombre
Comprobar que todas las variables estn declaradas
Comprobar que las longitudes y tipos de las variables sean correctos.
o Clculo. Intenta localizar errores derivados del uso de las variables. Por ejemplo:
Comprobar que no se producen overflow o underflow (valores fuera de
rango, por encima o por debajo) en los clculos o divisiones por cero.
o Comparacin. Intenta localizar errores en las comparaciones realizadas en
instrucciones tipo If-Then-Else, While, etc. Por ejemplo:
Comprobar que no existen comparaciones entre variables con diferentes
tipos de datos o si las variables tienen diferente longitud.
N.Juristo/A. Moreno
Pg.25
N.Juristo/A. Moreno
Pg.26
finalmente las lneas de cdigo). Este tipo de tarea se realiza de arriba hacia abajo, partiendo de la
especificacin (arriba o nodo raz) y llegando a n lneas de cdigo (abajo o nodos hojas).
Pues bien, si queremos obtener una especificacin a partir de un cdigo deberemos hacer este
mismo recorrido pero en sentido contrario: de abajo hacia arriba. Por tanto, deberemos comenzar
con las lneas de cdigo, agruparlas en estructuras elementales, y stas en funciones y stas en un
todo que ser la descripcin del comportamiento del programa. En este caso no estamos trabajando
descomponiendo, sino componiendo. La tarea que se realiza es de abstraccin. De ah el nombre de
la tcnica: abstraccin sucesiva (ir sucesivamente ascendiendo en niveles cada vez superioresabstrayendo qu hace cada elemento primero las lneas, luego las estructuras, finalmente las
funciones).
Esta tcnica requiere que el inspector lea una serie de lneas de cdigo y que abstraiga la funcin
que estas lneas computan. El inspector debe repetir este procedimiento hasta que la funcin final
del cdigo que se est inspeccionando se haya abstrado y pueda compararse con la especificacin
original del programa.
Ms concretamente, el proceso que se debe seguir para realizar la abstraccin sucesiva es el
siguiente:
1. Leer por encima el cdigo para tener una idea general del programa.
2. Determinar las dependencias entre las funciones individuales del cdigo fuente (quin
llama a quin). Para esto puede usarse un rbol de llamadas para representar tales
dependencias comenzando por las hojas (funciones que no llaman a nadie) y acabando
por la raz (funcin principal).
3. Comprender qu hace cada funcin. Para ello se deber: Entender la estructura de cada
funcin individual identificando las estructuras elementales (secuencias, condicionales,
bucles, etc.) y marcndolas; Combinar las estructuras elementales para formar
estructuras ms grandes hasta que se haya entendido la funcin entera. Es decir, para
cada funcin y comenzando desde las funciones hoja y acabando por la raz:
3.1. Identificar las estructuras elementales de cada funcin y marcarlas de la
ms interna a la ms externa.
3.2. Determinar el significado de cada estructura comenzando con la ms
interna. Para ello pueden seguirse las siguientes recomendaciones:
Usar los nmeros de lnea (lneas x-y) para identificar las lneas que
abarca una estructura e indicar a su lado qu hace.
N.Juristo/A. Moreno
Pg.27
4. Combinar el comportamiento de cada funcin y las relaciones entre ellas para entender
el comportamiento del programa entero. El comportamiento deber describirse en texto.
Esta descripcin es la especificacin del programa obtenida a partir del cdigo.
5. Comparar la especificacin obtenida con la especificacin original del programa. Cada
punto donde especificacin original y especificacin generada a partir del cdigo no
coincidan es un defecto. Anotar los defectos en una lista.
Veamos un breve ejemplo para entender mejor la tcnica. El programa count ya lo conoces pues
lo has usado para practicar con la tcnica de lectura con listas de comprobacin. Centrmonos en el
siguiente trozo de especificacin original:
Si alguno de los ficheros que se le pasa como argumento no existe, aparece por la salida de
error el mensaje de error correspondiente y se contina procesando el resto de los ficheros.
Que se implementa mediante las siguientes lneas de cdigo entresacadas del programa count.
if (argc > 1 && (fp=fopen(argv[i], "r")) == NULL) {
fprintf (stdout, "can't open %s\n", argv[i]);
exit(1)
}
La abstraccin de estas lneas sera:
Lnea 1 Si no hay ficheros que coincidan con el argumento (fp=fopen(argv[i], "r")) ==
NULL)
Lnea 2 Se imprime por la salida estndar (stdout)el mensaje de que no se puede abrir el
fichero (indicando el nombre del fichero)
Lnea 3 Se sale del programa
Que se corresponde con la siguiente descripcin:
Se proporcionan argumentos, pero no hay ficheros con nombres correspondientes a los
argumentos. En este caso, el programa se para con un mensaje de error que sale por la
salida estndar.
Ntese que las especificaciones no coinciden en algunos puntos. En la Tabla 2 se ve la comparacin
y aparecen en negrita sealadas las diferencias.
N.Juristo/A. Moreno
Pg.28
ESPECIFICACIN ORIGINAL
N.Juristo/A. Moreno
Pg.29
asunciones son consistentes y detalladas lo suficiente para asegurar que las funciones puedan ser
correctamente implementadas y usadas.
N.Juristo/A. Moreno
Pg.30
Evaluacin
Fallos
Prueba
Datos de tasa
de error
Configuracin
de la
Prueba
Depuracin
Correciones
Resultados
esperados
Modelo de
Fiabilidad
Prediccin
Fiabilidad
Una buena prueba ha de tener una alta probabilidad de encontrar un fallo. Para alcanzar este
objetivo el responsable de la prueba debe entender el software e intentar desarrollar una
imagen mental de cmo podra fallar.
N.Juristo/A. Moreno
Pg.31
Una buena prueba debe centrarse en dos objetivos: 1) probar si el software no hace lo que
debe hacer, y 2) probar si el software hace lo que no debe hacer.
Una buena prueba no debe ser redundante. El tiempo y los recursos son limitados, as que
todas las pruebas deberan tener un propsito diferente.
Una buena prueba debera ser la mejor de la cosecha. Esto es, se debera emplear la
prueba que tenga la ms alta probabilidad de descubrir una clase entera de errores.
Una buena prueba no debera ser ni demasiado sencilla ni demasiado compleja, pero si se
quieren combinar varias pruebas a la vez se pueden enmascarar errores, por lo que en
general, cada prueba debera realizarse separadamente.
Veamos ahora cules son las tareas a realizar para probar un software:
1. Diseo de las pruebas. Esto es, identificacin de la tcnica o tcnicas de pruebas que se
utilizarn para probar el software. Distintas tcnicas de prueba ejercitan diferentes criterios
como gua para realizar las pruebas. Seguidamente veremos algunas de estas tcnicas.
2. Generacin de los casos de prueba. Los casos de prueba representan los datos que se
utilizarn como entrada para ejecutar el software a probar. Ms concretamente los casos de
prueba determinan un conjunto de entradas, condiciones de ejecucin y resultados
esperados para un objetivo particular. Como veremos posteriormente, cada tcnica de
pruebas proporciona unos criterios distintos para generar estos casos o datos de prueba. Por
lo tanto, durante la tarea de generacin de casos de prueba, se han de confeccionar los
distintos casos de prueba segn la tcnica o tcnicas identificadas previamente. La
generacin de cada caso de prueba debe ir acompaada del resultado que ha de producir el
software al ejecutar dicho caso (como se ver ms adelante, esto es necesario para detectar
un posible fallo en el programa).
3. Definicin de los procedimientos de la prueba. Esto es, especificacin de cmo se va a
llevar a cabo el proceso, quin lo va a realizar, cundo,
4. Ejecucin de la prueba, aplicando los casos de prueba generados previamente e
identificando los posibles fallos producidos al comparar los resultados esperados con los
resultados obtenidos.
5. Realizacin de un informe de la prueba, con el resultado de la ejecucin de las pruebas, qu
casos de prueba pasaron satisfactoriamente, cules no, y qu fallos se detectaron.
Tras estas tareas es necesario realizar un proceso de depuracin de las faltas asociadas a los fallos
identificados. Nosotros nos centraremos en el segundo paso, explicando cmo distintas tcnicas de
pruebas pueden proporcionar criterios para generar distintos datos de prueba.
N.Juristo/A. Moreno
Pg.32
Tcnicas de caja negra o funcionales, que realizan pruebas sobre la interfaz del programa a
probar, entendiendo por interfaz las entradas y salidas de dicho programa. No es necesario
conocer la lgica del programa, nicamente la funcionalidad que debe realizar.
La Figura 3 representa grficamente la filosofa de las pruebas de caja blanca y caja negra. Como se
puede observar las pruebas de caja blanca necesitan conocer los detalles procedimentales del
cdigo, mientras que las de caja negra nicamente necesitan saber el objetivo o funcionalidad que el
cdigo ha de proporcionar.
A primera vista parecera que una prueba de caja blanca completa nos llevara a disponer de un
cdigo perfectamente correcto. De hecho esto ocurrira si se han probado todos los posibles
caminos por los que puede pasar el flujo de control de un programa. Sin embargo, para programas
de cierta envergadura, el nmero de casos de prueba que habra que generar sera excesivo, ntese
que el nmero de caminos incrementa exponencialmente a medida que el nmero de sentencias
condicionales y bucles aumenta. Sin embargo, este tipo de prueba no se desecha como
impracticable. Se pueden elegir y ejercitar ciertos caminos representativos de un programa.
Por su parte, tampoco sera factible en una prueba de caja negra probar todas y cada una de las
posibles entradas a un programa, por lo que anlogamente a como ocurra con las tcnicas de caja
blanca, se seleccionan un conjunto representativo de entradas y se generan los correspondientes
casos de prueba, con el fin de provocar fallos en los programas.
En realidad estos dos tipos de tcnicas son tcnicas complementarias que han de aplicarse al realizar
una prueba dinmica, ya que pueden ayudar a identificar distintos tipos de faltas en un programa.
A continuacin, se describen en detalle los procedimientos propuestos por ambos tipos de tcnicas
para generar casos de prueba.
N.Juristo/A. Moreno
Pg.33
estructura del programa. Se examina as la lgica interna del programa sin considerar los aspectos
de rendimiento.
El objetivo de la tcnica es disear casos de prueba para que se ejecuten, al menos una vez, todas
las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como falsa.
Como se ha indicado ya, puede ser impracticable realizar una prueba exhaustiva de todos los
caminos de un programa. Por ello se han definido distintos criterios de cobertura lgica, que
permiten decidir qu sentencias o caminos se deben examinar con los casos de prueba. Estos
criterios son:
-
Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia
en el programa se ejecute, al menos, una vez.
Cobertura de Decisin: Se escriben casos de prueba suficientes para que cada decisin en el
programa se ejecute una vez con resultado verdadero y otra con el falso.
Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condicin
en una decisin tenga una vez resultado verdadero y otra falso.
Cobertura de Condicin Mltiple: Se escriben casos de prueba suficientes para que todas
las combinaciones posibles de resultados de cada condicin se invoquen al menos una vez.
Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos
los caminos de un programa. Entendiendo camino como una secuencia de sentencias
encadenadas desde la entrada del programa hasta su salida.
N.Juristo/A. Moreno
Pg.34
Nodos: representan cero, una o varias sentencias en secuencia. Cada nodo comprende como
mximo una sentencia de decisin (bifurcacin).
Regiones: reas delimitadas por aristas y nodos. Cuando se contabilizan las regiones de un
programa debe incluirse el rea externa como una regin ms.
Nodos predicado: cuando en una condicin aparecen uno o ms operadores lgicos (AND,
OR, XOR, ...) se crea un nodo distinto por cada una de las condiciones simples. Cada nodo
generado de esta forma se denomina nodo predicado. La Figura 4 muestra un ejemplo de
condicin mltiple.
IF a OR b
THEN
x
ELSE
y
ENDIF
Nodos
Predicado
a
False
b
True
x
False
y
As, cada construccin lgica de un programa tiene una representacin. La Figura 5 muestra dichas
representaciones.
N.Juristo/A. Moreno
Pg.35
Secuencia
opcin N
While
CASE
if
END CASE
opcin2
Repeat
opcin1
La Figura 6 muestra un grafo de flujo del diagrama de mdulos correspondiente. Ntese cmo la
estructura principal corresponde a un while, y dentro del bucle se encuentran anidados dos
constructores if.
1
Aristas
Nodos
6
7
Regin
8
N.Juristo/A. Moreno
Pg.36
1
Aristas
Nodos
4
R2
R1
R3
Regin
8
R4
N.Juristo/A. Moreno
Pg.37
Esta complejidad ciclomtica determina el nmero de casos de prueba que deben ejecutarse para
garantizar que todas las sentencias de un programa se han ejecutado al menos una vez, y que cada
condicin se habr ejecutado en sus vertientes verdadera y falsa. Veamos ahora, cmo se identifican
estos caminos.
N.Juristo/A. Moreno
Pg.38
4.2.1.1.4 Derivar los casos de prueba que fuerzan la ejecucin de cada camino.
El ltimo paso es construir los casos de prueba que fuerzan la ejecucin de cada camino. Una forma
de representar el conjunto de casos de prueba es como se muestra en la Tabla 3.
Caso de Prueba
Resultado Esperado
En el Anexo L se encuentra un posible ejemplo de pruebas de Caja Blanca para que los alumnos
trabajen con l junto con su solucin. En el Anexo N se muestra un ejercicio propuesto para que los
alumnos se ejerciten en esta tcnica de pruebas. El cdigo correspondiente ha sido ya utilizado para
la evaluacin con tcnicas estticas.
Particiones de Equivalencia.
Pruebas de Comparacin.
Anlisis Causa-Efecto.
De ellas, las tcnicas que estudiaremos son las dos primeras, esto es, Particiones de Equivalencia y
Anlisis de Valores Lmite.
N.Juristo/A. Moreno
Pg.39
Condicin Externa
Si una condicin de entrada especifica un valor o nmero de valores, identificar una clase
vlida y dos clases no vlidas. Por ejemplo, si tenemos que puede haber desde uno hasta
seis propietarios en la vida de un coche. Habr una clase vlida y dos no vlidas: no hay
propietarios y ms de seis propietarios.
N.Juristo/A. Moreno
Pg.40
Si una condicin de entrada especifica una situacin que debe ocurrir, esto es, es lgica,
identificar una clase vlida y una no vlida. Por ejemplo, el primer carcter del identificador
debe ser una letra. La clase vlida sera identificador que comienza con letra, y la clase
invlida sera identificador que no comienza con letra.
En general, si hay alguna razn para creer que los elementos de una clase de equivalencia
no se tratan de igual modo por el programa, dividir la clase de equivalencia entre clases de
equivalencia ms pequeas para cada tipo de elementos.
En lugar de seleccionar cualquier caso de prueba de las clases vlidas e invlidas, se eligen
los casos de prueba en los extremos.
N.Juristo/A. Moreno
Pg.41
En lugar de centrase slo en el dominio de entrada, los casos de prueba se disean tambin
considerando el dominio de salida.
Las pautas para desarrollar casos de prueba con esta tcnica son:
-
N.Juristo/A. Moreno
Pg.42
Tanto las pruebas de caja blanca como las de caja negra han de aplicarse para probar de la manera
ms completa posible un mdulo. Ntese que las pruebas de caja negra (los casos de prueba) se
pueden especificar antes de que mdulo sea programado, no as las pruebas de caja blanca.
N.Juristo/A. Moreno
Pg.43
Mc
Mb
Ma
C1
C3
Grupo 1
Grupo 3
C2
Grupo 2
N.Juristo/A. Moreno
Pg.44
M1
R3
M2
M4
R7
R5
R6
M5
M6
M3
M7
Participacin activa del usuario, que debe ejecutar los casos de prueba ayudado por
miembros del equipo de pruebas.
Estn enfocadas a probar los requisitos de usuario, o mejor dicho a demostrar que no se
cumplen los requisitos, los criterios de aceptacin o el contrato. Si no se consigue demostrar
esto el cliente deber aceptar el producto
N.Juristo/A. Moreno
Pg.45
Decidir las pruebas a efectuar para los mdulos que no han cambiado y que han sido
afectados por los cambios producidos.
Este tipo de pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en el
software, como durante el mantenimiento.
N.Juristo/A. Moreno
Pg.46
N.Juristo/A. Moreno
Pg.47
N.Juristo/A. Moreno
Pg.48
6. HERRAMIENTAS DE PRUEBA
OpenLoad Tester
Las caractersticas de esta herramienta son las siguientes:
OpenLoad Tester es una herramienta de optimizacin de rendimiento basada en navegador
para pruebas de carga y stress de sitios web dinmicos.
Permite elaborar escenarios de ejecucin y ejecutarlos de forma repetida, simulando la
carga de un entorno de produccin real de nuestra aplicacin como si mltiples usuarios
estuvieran usndola
Benchmark Factory
Las caractersticas de esta herramienta son las siguientes:
N.Juristo/A. Moreno
Pg.49
DataFactory
Las caractersticas de esta herramienta son las siguientes:
DataFactory, ayuda a la creacin automtica de juegos de ensayo o casos de prueba
basados en la funcionalidad de las aplicaciones (casos de uso), que facilitan la labor de
tener que crearlos manualmente y tpicamente, se utilizan junto a las herramientas de
pruebas de carga.
PerformaSure
Las caractersticas de esta herramienta son las siguientes:
PerfomaSure, es una herramienta de diagnstico de rendimiento para el anlisis en
entornos distribuidos J2EE, que permite el seguimiento de los problemas de rendimiento
detectados en tiempo real, desde la transaccin del usuario final en fase de produccin,
hasta la lnea de cdigo fuente que genera el problema.
Spotlight
N.Juristo/A. Moreno
Pg.50
JProbe
Esta herramienta, permite detectar los 'puntos calientes' de los componentes de una
aplicacin JAVA, tales como el uso de la memoria, el uso del CPU, los hilos de
ejecucin,... y a partir de ellos, bajar al nivel del cdigo fuente que los provoca ofreciendo
una serie de consejos o buenas prcticas de codificacin para la resolucin del problema.
N.Juristo/A. Moreno
Pg.51
A.2
A.3
INTRODUCCIN
A.1.1
PROPSITO
A.1.2
A.1.3
A.1.4
DESCRIPCIN GENERAL
A.2.1
VISIN GENERAL
A.2.2
A.2.3
A.2.4
A.2.5
RESTRICCIONES Y SUPOSICIONES
REQUISITOS ESPECFICOS
A.3.1
A.3.2
REQUISITOS FUNCIONALES
A.3.1.1
Requisitos Generales
A.3.1.2
A.3.1.3
A.3.1.4
A.3.1.5
A.3.1.6
Interfaces de usuario
A.3.2.2
Interfaces de hardware
A.3.3
REQUISITOS DE RENDIMIENTO
A.3.4
OTROS REQUISITOS
A.1. INTRODUCCIN
A.1.1. Propsito
N.Juristo/A. Moreno
Pg.52
Este documento presenta la especificacin requisitos de un sistema de gestin de vdeos para ABC
vdeo. Estos requisitos representan el comportamiento del sistema, y se ha obtenido mediante
entrevistas con los directivos de ABC vdeo y la documentacin proporcionada por stos. La
finalidad de este documento es, por tanto, triple:
1. Demostrar a la direccin de ABC Vdeo que el ingeniero de requisitos ha entendido
perfectamente los requisitos del sistema.
2. Para obtener comentarios de la direccin de ABC Vdeo con respecto al conocimiento
actual del sistema, y en particular, para servir como base de acuerdo para el problema
que ha de ser resuelto.
3. Y finalmente, para servir de gua durante el diseo del sistema.
A.1.2. mbito del Sistema
Este documento se centra principalmente en los requisitos para un sistema de gestin de vdeos. Por
tanto, los requisitos para otro tipo de operaciones de ABC Vdeo estn fuera del alcance de este
documento. Sin embargo, este documento tambin especifica los requisitos para cada entidad
externa al sistema, las cuales se comunicarn mediante una interfaz con el sistema.
A.1.3. Definiciones, acrnimos, abreviaturas
Cliente.
Una persona que tiene una cuenta y alquilar cintas de vdeo a ABC Vdeo.
Cuenta.
Registro de informacin de un cliente, que permite transacciones, tales como alquileres.
Productos.
Cintas de vdeo que pueden ser alquiladas. En el futuro este concepto podr albergar juegos,
CDs, etc.
Recibo.
Recibo de cada transaccin.
PC.
Hace referencia al ordenador que procesar todas las transacciones.
Tarjeta ABC.
Esta tarjeta la obtiene cada cliente despus de ser registrado en el sistema, es decir, cuando se abre
una cuenta. En esta tarjeta hay un cdigo de barras con el nmero de cuenta que puede ser ledo por
un lector de cdigos de barras.
A.1.4. Visin general del documento
El resto del documento consta de en dos secciones. La Seccin 2 realiza una descripcin informal
del sistema basndose en la informacin obtenida de la directiva de ABC Vdeo. La Seccin 3
describe los requisitos funcionales y los requisitos de rendimiento.
Los clientes eligen al menos un vdeo para alquilar. El nmero mximo de cintas que un
cliente puede tener alquiladas es 20. El nmero de cuenta del cliente se introduce para
obtener informacin del cliente y realizar un pedido. Cada cliente recibe una tarjeta
identificativa de ABC. Esta tarjeta identificativa tiene un cdigo de barras que se lee con
un lector de cdigos de barras. El cdigo de barras de cada cinta que se va alquilar, se
N.Juristo/A. Moreno
Pg.53
Adems, para facilitar las operaciones usuales de ABC Vdeo, el sistema gestionar una variedad de
informacin til para la direccin. El sistema almacenar informacin sobre cada cliente de ABC
Vdeo adems de histricos de transacciones de alquileres.
A.2.4. Caractersticas de los usuarios
El sistema ser usado por la directiva de ABC Vdeo, los dependientes e indirectamente por los
clientes. Desde el punto de vista del sistema, los dependientes y la direccin son idnticos. Algunas
operaciones del sistema solo son accesibles para la direccin (tales como imprimir los informes
diarios) y estn protegidas por un clave.
Los dependientes no necesitan tener conocimientos informticos, pero necesitarn estar
familiarizados con los procedimientos del software para alquileres y devoluciones. La direccin
deber familiarizarse con las capacidades del sistema, incluidas la programacin de tarifas,
realizacin de informes y mantenimiento de informacin sobre clientes e informacin sobre videos.
Los clientes no necesitan ninguna experiencia con el sistema, pero debern llevar su tarjeta de ABC.
N.Juristo/A. Moreno
Pg.54
ABC Vdeo actualizar el hardware cuando sea necesario para el sistema, incluyendo la
compra de escneres, cajas registradoras, una unidad de cinta, y la actualizacin del
disco duro si es necesario.
El contenido inicial del inventario de videos esta fuera del alcance de este documento.
Descripcin.
En el estado inicial del sistema se muestra por pantalla el men principal. Desde el men
principal, el dependiente puede elegir una de las siguientes opciones:
1. Alquilar cintas.
2. Devolver cintas.
N.Juristo/A. Moreno
Pg.55
3.
4.
5.
6.
7.
8.
9.
Entrada.
El empleado elige una opcin.
Procesamiento.
Procesar la opcin.
Salida.
Mostrar los mens para la opcin elegida.
Requisito funcional 2
Descripcin.
El sistema mantiene un inventario de cintas de videos almacenando informacin descriptiva y el
estado actual del vdeo.
Requisito funcional 3
Descripcin.
El sistema mantiene un registro de transacciones para cada cliente proporcionando informacin
sobre l y las cintas que tiene alquiladas.
Descripcin.
El cliente lleva la tarjeta ABC consigo. El nmero de cuenta del cliente se lee con el lector de
cdigo de barras para que el dependiente recupere el registro de transacciones.
Entrada.
Se introduce el nmero de cuenta mediante el cdigo de barras de la tarjeta.
Procesamiento.
Bsqueda en el registro de transacciones.
Salida.
Mostrar el registro de transacciones.
Requisito funcional 5
Descripcin.
El cliente no tiene la tarjeta consigo. El nmero de cuenta del cliente lo introduce el
dependiente a travs del teclado para obtener el registro de transacciones.
N.Juristo/A. Moreno
Pg.56
Entrada.
El nmero de cuenta se introduce por el teclado.
Procesamiento.
Bsqueda del registro de transacciones.
Salida.
Mostrar el registro de transacciones.
Requisito funcional 6
Descripcin.
Se introduce el cdigo de barras de cada cinta que el cliente va a alquilar.
Entrada.
Se introduce mediante el lector el cdigo de barras de cada cinta que va a ser alquilada.
Procesamiento.
Obtener la informacin sobre el vdeo del inventario.
Salida.
Mostrar el nombre del la cinta de vdeo y el precio de alquiler.
Requisito funcional 7
Descripcin.
El nmero mximo de cintas que pueden alquilarse en una transaccin es 20.
Entrada.
Se introduce el identificador de las cintas mediante el lector el cdigo de barras de cada cinta
que va a ser alquilada.
Procesamiento.
Si el cdigo introducido corresponde a la cinta nmero 21, el alquiler se rechaza.
Salida.
Se muestra un mensaje de error.
Requisito funcional 8
Descripcin.
Cuando se han introducido todas las cintas el sistema calcula el total.
Entrada.
La tecla Intro se pulsa despus de haber introducido la ltima cinta.
Procesamiento.
Calcular el total a pagar. El total es la suma de los recargos, otras tarifas y los precios de los
videos a alquilar.
Salida.
El total a pagar.
N.Juristo/A. Moreno
Pg.57
Requisito funcional 9
Descripcin.
El dependiente recoge el dinero del cliente e introduce la cantidad recibida en el sistema.
Entrada.
Cantidad recibida por el dependiente, introducida por teclado.
Procesamiento.
Calcular el cambio.
Salida.
Mostrar el cambio total.
Requisito funcional 10
Descripcin.
Cuando el dependiente presiona la tecla de la opcin orden completa (definida por el sistema)
el alquiler se completa y el fichero de inventario de videos es actualizado.
Entrada.
El dependiente pulsa la tecla de opcin orden completa.
Procesamiento.
Actualizar el fichero de inventario de videos. Cerrar la transaccin de alquilar.
Salida.
El fichero de inventario se actualiza. El fichero de transacciones de alquiler se actualiza.
Requisito funcional 11
Descripcin.
Al finalizar el alquiler, la transaccin se almacena e imprime.
Entrada.
Cerrar el alquiler actual.
Procesamiento.
Almacenar el alquiler e imprimir el recibo que el cliente tiene que firmar. Volver al estado
inicial. Los recibos sern mantenidos en un fichero se que mantendr durante un mes despus
de que las cintas se hayan devuelto.
Salida.
Imprimir el recibo. Mostrar el men inicial.
Descripcin.
El cdigo de barras del vdeo se introduce en el sistema.
Entrada.
El cdigo de barras del vdeo.
Procesamiento.
N.Juristo/A. Moreno
Pg.58
Salida.
Mostrar el registro de transaccin de alquiler.
Requisito funcional 13
Descripcin.
Cuando se recupera el registro de transacciones, se anota en el registro del vdeo la fecha de
devolucin.
Entrada.
El cdigo de barras del vdeo a alquilar.
Procesamiento.
Se obtienen el registro de transacciones y el del inventario del video. Se anota el da de
devolucin en el registro.
Salida.
Actualizar el registro de inventario y las transacciones de alquiler.
Requisito funcional 14
Descripcin.
Si existe un recargo por retraso, se puede pagar en ese momento; o el dependiente puede pulsar
la tecla de orden completa con lo cual se actualiza el alquiler con la nueva fecha de
devolucin y se calculan los recargos.
Entrada.
Abono o clculo del recargo
Procesamiento.
Actualizacin del registro de transacciones. Ir al estado inicial.
Salida.
Actualizar el fichero de transacciones.
Descripcin.
Un nuevo cliente quiere alquilar cintas de video. El dependiente introduce toda la informacin
necesaria, imprime el cdigo de barras para la tarjeta ABC y lo pega una tarjeta nueva. La
tarjeta se entrega al cliente.
Entrada.
El dependiente introduce la siguiente informacin: Nombre, direccin e informacin sobre la
tarjeta de crdito del cliente.
Procesamiento.
Crea un nuevo registro de transacciones de alquiler para el cliente. El sistema asigna un nmero
de cuenta al cliente e imprime el cdigo de barras. Ir al estado inicial.
Salida.
N.Juristo/A. Moreno
Pg.59
Descripcin.
Antes que se pueda alquilar una cinta nueva se debe introducir toda la informacin necesaria. El
cdigo de barras es impreso y el dependiente tiene que pegarlo en el vdeo.
Entrada.
Una cinta de vdeo se caracteriza por los siguientes atributos: nombre del vdeo, precio de
alquiler e identificador de la cinta.
Procesamiento.
Crea un nuevo registro en el inventario de cintas de vdeo para la cinta.
Salida.
Se genera un registro en el inventario de videos. La cinta puede ser alquilada. Se imprime el
cdigo de barras para la cinta.
Requisito funcional 17
Descripcin.
El dependiente puede modificar la informacin de un vdeo o un cliente.
Entrada.
El dependiente introduce nueva informacin bien sobre un vdeo o sobre cliente.
Procesamiento.
Actualizar los datos del fichero de inventario de vdeos.
Salida.
Mostrar el cambio si ste tiene lugar.
Descripcin.
Solo la direccin puede borrar un cliente o un vdeo.
Entrada.
El directivo introduce el nmero de cuenta de un vdeo o cliente.
Procesamiento.
Borrar el vdeo o cliente.
Salida.
Mostrar el cambio si este tiene lugar.
Requisito funcional 19
N.Juristo/A. Moreno
Pg.60
Descripcin.
El directivo puede imprimir diariamente informes o algunas estadsticas.
Entrada.
El directivo selecciona que clase de informacin quieren tener. Pueden elegir cualquier
elemento de la siguiente lista:
- Informes diarios
- Lista de clientes registrados durante algn periodo de tiempos
- Lista de clientes morosos
- Lista de clientes con alquileres retrasados
- Lista de cintas organizadas por estados
- Lista de cintas no alquiladas durante un cierto nmero de das.
- Nmero de alquileres (por copia, ttulo, tipo) durante un cierto periodo de tiempo.
- Nmero de das alquilados (por mes, ao, copia y ttulo)
- Histricos de alquileres de los clientes.
Procesamiento.
Recoger toda la informacin necesaria para la peticin realizada e imprimirla.
Salida.
El informe impreso.
Requisito de rendimiento 2
El sistema tendr que responder rpidamente. El tiempo tpico de respuesta para la lectura del
cdigo de barras de un vdeo que va a ser alquilado debe ser inferior a 15 seg. En casi todos los
casos el tiempo de respuesta deber estar por debajo de 5 minutos, con la posible excepcin de la
recuperacin de informacin desde una cinta de backup de 8mm o de un disco.
N.Juristo/A. Moreno
Pg.61
N.Juristo/A. Moreno
Pg.62
Son los requisitos completos en el sentido de que si un producto satisface todos los
requisitos, ser aceptable?
Surgen dudas acerca de alguna parte de los requisitos? Son algunas partes del
sistema imposibles de implementar y se han incluido simplemente para satisfacer al
cliente?
Estn todos los requisitos escritos en el lenguaje del usuario? Piensan eso los
usuarios?
Evitan todos los requisitos conflictos con otros requisitos?
Evitan los requisitos especificar el diseo?
Estn los requisitos a un nivel bastante consistente? Debera especificarse algn
requisito con ms detalle? Debera especificarse algn requisito con menos
detalles?
Son los requisitos lo suficientemente claros para poderse enviar a un grupo
independiente para su implementacin y que lo entiendan?
Es cada requisito relevante al problema y a su solucin? Se puede trazar cada uno
al origen en el entorno del problema?
Es cada requisito testeable? Sera posible para un grupo independiente de pruebas
determinar si cada requisito se ha satisfecho?
Se han especificado todos los cambios posibles a los requisitos, incluyendo la
probabilidad de cada cambio?
N.Juristo/A. Moreno
Pg.63
N.Juristo/A. Moreno
Pg.64
N.Juristo/A. Moreno
Pg.65
Se usan los gotos nicamente como ltimo recurso, y nicamente para hacer el
cdigo ms legible y mantenible?
Si se usa un goto por eficiencia, se ha medido y documentado la ganancia en
eficiencia?
Estn limitados los gotos a una etiqueta por rutina?
Van todos los gotos hacia delante, no hacia atrs?
Se usan todas las etiquetas de los gotos?
Return
N.Juristo/A. Moreno
Pg.66
Recursividad
Cadenas if-then-else-if
Sentencias case
N.Juristo/A. Moreno
Pg.67
Estructuras de Control
Sentencias Individuales
N.Juristo/A. Moreno
Pg.68
Nombre de Datos
Son los nombres de los tipos de datos lo suficientemente descriptivos para ayudar
a documentar las declaraciones de los datos? Se usan especficamente para ese
propsito?
Se han nombrado bien las variables?
Se han usado las variables nicamente para el propsito por el cual se han
nombrado?
Tienen los contadores de bucle nombres ms informativos que i,j, y k?
Se usan tipos enumerados bien nombrados en lugar de flags o variables
booleanas?
Se usan constantes declaradas en lugar de nmeros mgicos o cadenas mgicas?
Distinguen las convenciones de nombrado entre nombres de tipos, tipos
enumerados, constantes declaradas, variables locales, variables de mdulo y
variables globales?
Control
N.Juristo/A. Moreno
Pg.69
Son las estructuras de control simples de tal modo que minimizan la complejidad?
Se ha minimizado el nmero de anidamientos?
Diseo
Sentencias y prrafos
Declaraciones de Datos
N.Juristo/A. Moreno
Pg.70
Rutinas
N.Juristo/A. Moreno
Pg.71
N.Juristo/A. Moreno
Pg.72
462
3621
fichero1
FILE *fopen(Nombre, r)
Abre el fichero indicado para lectura y devuelve un puntero al mismo, en caso de error,
devuelve NULL.
N.Juristo/A. Moreno
Pg.73
N.Juristo/A. Moreno
Pg.74
c, i, inword;
FILE
*fp;
long
long
i = 1;
do {
if (argc > 1 && (fp=fopen(argv[i], "r")) == NULL) {
fprintf (stdout, "can't open %s\n", argv[i]);
exit (1);
}
linect = wordct = charct = 0;
inword = 0;
while ((c = getc(fp)) != EOF) {
++charct;
if (c == '\n')
++linect;
if (c == ' ' || c == '\t' || c == '\n')
inword = 0;
else if (inword == 0) {
inword = 1;
++wordct;
}
}
printf("%7ld %7ld %7ld", linect, wordct, charct);
if (argc > 1)
printf(" %s\n", *argv);
else
printf("\n");
N.Juristo/A. Moreno
Pg.75
fclose(fp);
tlinect += linect;
twordct += wordct;
tcharct += charct;
} while (++i <= argc);
if (argc > 1)
printf("%7ld %7ld %7ld total\n", linect, twordct, tcharct);
exit(0);
N.Juristo/A. Moreno
Pg.76
Abstraccin
21-29
Secuencia
Significado de los componentes:
21
22-23
24-29
24-30
charct := charct +1
c = otralinea linect := linect + 1 | ()
c = espacio inword := 0 |
(inword = 0 inword, wordct := 1, wordct + 1 | () )
14-39
Secuencia
N.Juristo/A. Moreno
Para determinar el significado de este trozo, se incluyen las lneas 18-19 y se miran
las tareas de las variables:
1. La variable charct se incrementa en los cuatro casos; es decir, cuenta cada
carcter.
2. La variable linect slo se incrementa is se lee otralinea; es decir, cuenta
lneas.
3. La variable inword es un switch que toma los valores 0 y 1.
Pg.77
31
32-35
36
37-39
10
12-40
N.Juristo/A. Moreno
Pg.78
N.Juristo/A. Moreno
Pg.79
2. Falta en lnea 14: La variable fp no est inicializada en caso de que la entrada se tome de
stdin (entrada estndar).
{Omisin, Inicializacin}
Causa fallo: El programa no puede leer de la entrada estndar
.
N.Juristo/A. Moreno
Pg.80
4. Falta en lnea 16: El componente termina con exit(1), donde debera haberse usado un
continue.
{Comisin, Control}
Causa fallo: Si no se encuentra un fichero, el programa para en lugar de continuar con los otro
ficheros; tampoco se imprime una suma
.
7. Falta en lnea 41: Argc se compara con 1, y debera ser comparado con 2.
{Comisin, Computacin}
Causa fallo: El programa imprime sumas incluso cuando slo se procesa un nico fichero.
14
count
14
count
14
count
43
total
N.Juristo/A. Moreno
Pg.81
{
int
c, i, inword;
FILE
*fp;
long
long
i = 1;
do {
if (argc > 1 && (fp=fopen(argv[i], "r")) == NULL) {
fprintf (stdout, "can't open %s\n", argv[i]);
exit (1);
}
linect = wordct = charct = 0;
inword = 0;
while ((c = getc(fp)) != EOF) {
++charct;
if (c == '\n')
++linect;
if (c == ' ' || c == '\t' || c == '\n')
inword = 0;
else if (inword == 0) {
inword = 1;
++wordct;
}
}
printf("%7ld %7ld %7ld", linect, wordct, charct);
if (argc > 1)
printf(" %s\n", *argv);
else
printf("\n");
fclose(fp);
tlinect += linect;
twordct += wordct;
tcharct += charct;
} while (++i <= argc);
if (argc > 1)
printf("%7ld %7ld %7ld total\n", linect, twordct, tcharct);
N.Juristo/A. Moreno
Pg.82
exit(0);
}
N.Juristo/A. Moreno
Pg.83
Descripcin
tokens lee de la entrada estndar, cuenta todos los tokens alfanumricos que aparecen e imprime el
nmero de veces que aparecen, siguiendo un orden lexicogrfico ascendente.
Opciones
-m cuenta: Indica el nmero mnimo de veces que han de aparecer los tokens en la
entrada para que aparezca en la salida.
Ver tambin
wc(1), sort(1), uniq(1).
N.Juristo/A. Moreno
Pg.84
#include <stdio.h>
#include <string.h>
#include <assert.h>
int Ignore = 0;
int Mincount = 0;
int Alpha = 0;
char MapAllowed[256];
*contents;
int
count;
TNODE *
install(string, tree) char *string; TNODE * tree;
{
int cond;
assert(string != NULL);
if (tree == NULL)
{
N.Juristo/A. Moreno
Pg.85
char *
getword(ioptr) FILE *ioptr;
{
static char string[1024];
char *ptr = string;
register int c;
assert(ioptr != NULL);
for (;;)
{
c = getc(ioptr);
if (c == EOF)
if (ptr == string)
return(NULL);
else
break;
if (!MapAllowed[c])
if (ptr == string)
continue;
N.Juristo/A. Moreno
Pg.86
else
break;
*ptr++ = MapAllowed[c];
}
*ptr = '\0';
return(string);
}
N.Juristo/A. Moreno
Pg.87
}
if (errcnt)
{
fprintf(stderr, "Usage: %s [-i] [-c chars] [-m count]\n", *argv);
return(1);
}
for (c = 'a'; c <= 'z'; c++)
MapAllowed[c] = c;
for (c = 'A'; c <= 'Z'; c++)
MapAllowed[c] = Ignore ? c - 'A' + 'a' : c;
if (!Alpha)
for (c = '0'; c <= '9'; c++)
MapAllowed[c] = c;
tokens(stdin);
return(0);
}
N.Juristo/A. Moreno
Pg.88
N.Juristo/A. Moreno
Pg.89
Nombre
series genera series numricas aditivas.
Uso
series comienzo fin [cadencia]
Descripcin
series imprime los nmeros reales comprendidos entre comienzo y fin, con el formato de uno por
lnea. series empieza por comienzo, al que suma o resta sucesivamente, segn corresponda, la
cadencia, para acercarse, posiblemente llegar a, pero nunca pasar el fin.
Si todos los argumentos son nmeros enteros, slo se generan nmeros enteros en la salida. La
cadencia debe ser un nmero distinto de cero; si no se especifica, se asume que es de tamao
unitario (1). En el resto de los casos, series imprime el mensaje de error correspondiente.
Ejemplo
Para contar de 1 a 100:
series 1 100
Para hacer lo mismo pero al revs:
series 100 1
Limitaciones
N.Juristo/A. Moreno
Pg.90
El nmero de dgitos significativos reportados est limitado. Si el ratio del rango de la series entre la
cadencia es demasiado grande, aparecern varios nmeros iguales.
La longitud mxima de una serie est limitada al tamao del mximo entero largo que pueda ser
representado en la mquina que est siendo usada. Si se excediese este valor, el resultado es
impredecible.
argv[1]
argv[3]
*Format = GFORMAT;
int
Onlyint;
double
Start;
double
Ending;
10e-10
Step = 1.0;
N.Juristo/A. Moreno
(!strcmp
(cadena,
cadena2));
Pg.91
nitems;
long
item;
double value;
int
nargs = argc - 1;
switch (nargs)
{
case 3:
if (! number(stepstr))
{
printf("El argumento #3 no es un numero: %s\n", stepstr);
exit(1);
}
case 2:
if (! number(startstr))
{
printf("El argumento #1 no es un numero: %s\n", endingstr);
exit(1);
}
if (! number(startstr))
{
printf("El argumento #2 no es un numero: %s\n", endingstr);
exit(1);
}
break;
N.Juristo/A. Moreno
Pg.92
default:
printf("USO comienzo fin cadencia\n");
exit(1);
}
Start
= atof(startstr);
Ending
= atof(endingstr);
= fabs(atof(stepstr));
Pg.93
2. Falta en lnea 70: En la condicin del if, se usa la variable startstr en lugar de endingstr.
{Comisin, Datos}
Causa fallo: El programa no reconoce como error el proporcionar un segundo argumento no
numrico.
4. Falta en lnea 94-95: El tratamiento del caso fin < comienzo se ha olvidado.
{Omisin, Computacin}
Causa fallo: No se genera salida en caso de que el valor de inicio sea mayor que el de fin.
N.Juristo/A. Moreno
Pg.94
Anexo H.
5. Hay puntos en los cuales no ests seguro de lo que deberas hacer porque el
requisito/especificacin funcional no est claro o no es consistente?
6. Tiene sentido el requisito/especificacin funcional con respecto a lo que sabes de la
aplicacin o de lo que se especifica en la descripcin general/introduccin?
N.Juristo/A. Moreno
Pg.95
3. Se pueden definir todos los tipos de datos? (es decir, se han especificado las unidades
correspondientes as como la precisin requerida)
Requisito funcional 3:Qu es un registro de transaccin?
4. Est disponible toda la informacin necesaria para hacer el diseo? Se han especificado
todas las condiciones para todos los objetos?
Requisitos funcionales 18/19: Cmo se restringen estas operaciones slo a la direccin?
5. Hay puntos en los cuales no ests seguro de lo que deberas hacer porque el
requisito/especificacin funcional no est claro o no es consistente?
Requisito funcional 2: Hay distintas formas potencialmente de interpretar estado actual para
clasificar las cintas: en tienda/alquilada, daada/buen estado, rebajada/precio normal, ...
N.Juristo/A. Moreno
Pg.96
N.Juristo/A. Moreno
Pg.97
Anexo I.
N.Juristo/A. Moreno
Pg.98
2. Puedes estar seguro de que los casos de prueba generados conducirn a los valores
correctos en las unidades correctas?
Requisito funcional 3: No se especifica lo que es informacin. Hay varias interpretaciones posibles
para sto.
3. Hay otras interpretaciones de este requisito que el implementador pueda hacer basndose
en la forma en que est definido el requisito/especificacin funcional? Afectar esto a los
casos de prueba que t generes?
Requisito funcional 2: Hay distintas formas potencialmente de interpretar estado actual para
clasificar las cintas: en tienda/alquilada, daada/buen estado, rebajada/precio normal, ...
N.Juristo/A. Moreno
Pg.99
N.Juristo/A. Moreno
Pg.100
7.
N.Juristo/A. Moreno
Pg.101
9. Estn claras y son correctas las condiciones iniciales para comenzar el escenario
operacional?
Requisito funcional 1: El men principal especificado por el estado inicial enumera nicamente las
funciones del cajero. No est claro cmo acceder a las funciones del directivo.
10. Estn bien definidas las interfaces entre funciones? Son compatibles? (es decir, estn
linkadas las entradas de una funcin a las salidas de la funcin previa?)
Requisito funcional 6: No se ha especificado que el nmero de cuenta debe introducirse antes de los
cdigos de barras de las cintas.
11. Puedes llegar a un estado del sistema que debe ser evitado? (por ejemplo por razones de
seguridad)
Falta un requisito funcional para cancelar transacciones, por tanto, el sistema puede llegar a un
estado en el cual se ha introducido informacin incorrecta y sta no se puede borrar.
12. Puede dar alguna parte del escenario operacional un resultado distinto dependiendo de
cmo se interprete un requisito/especificacin funcional?
Requisito funcional 10: No se especifica el significado de actualizar los distintos ficheros.
13. Tiene sentido el requisito/especificacin funcional teniendo en cuenta lo que sabes acerca
de la aplicacin de lo que se especifica en la descripcin general?
Requisito funcional 15: La descripcin general especifica que se necesita un nmero de telfono para
cada cliente, pero el requisito funcional para aadir un nuevo cliente no requiere que se introduzca
un nmero de telfono.
N.Juristo/A. Moreno
Pg.102
N.Juristo/A. Moreno
Pg.103
6.5.1.1 Defectos
Def.
Pg.
Req.
N.Juristo/A. Moreno
Clase
6.5.1.1.1 Descripcin
Pg.104
7 RF1
7 RF2
8 RF3
8 -
8 RF6
9 RF7
9 -
9 RF10
9 RF10
O/A
10
10 RF11
10 RF11
12
11 RF14
O/A
13
11 RF15
14
12 RF18, O
RF19
15
13
16
13
RR2
OR1
N.Juristo/A. Moreno
M
A
Pg.105
PROCEDURE Media;
*
Este procedimiento calcula la media de 100 o menos nmeros que se encuentran entre unos lmites; tambin calcula el
total de entradas y el total de nmeros vlidos.
INTERFACE RETURNS media, total.entrada, total.valido;
INTERFACE ACEPTS valor, minimo, maximo;
TYPE valor [1:100] IS INTEGER ARRAY;
TYPE media, total.entrada, total.valido, minimo, maximo, suma IS INTEGER;
TYPE i IS INTEGER;
i=1
total.entrada = total.valido = 0
suma = 0
DO WHILE VALOR [i] <> -999 and total.entrada < 100
Incrementar total.entrada en 1;
IF valor [i] >= minimo AND valor [i] <= maximo
THEN incrementar total.valido en 1;
suma = suma + valor [i];
ELSE ignorar
END IF
Incrementar i en 1;
END DO
IF total valido > 0
THEN media = suma/total.valido
ELSE media = -999
END IF
END MEDIA
4
7
3
5
6
11
12
10
13
N.Juristo/A. Moreno
Pg.106
1
2
3
10
4
12
11
13
6
7
8
9
El grafo tiene seis regiones por lo que el camino bsico estar formado por seis caminos en el
programa. Estos caminos pueden ser:
Camino 1: 1, 2, 3, 4, 5, 6, 7, 8, 9, 2 ,10, 11, 13
Camino 2: 1, 2, 3, 4, 5, 6, 7, 8, 9, 2 ,10, 12, 13
Camino 3: 1, 2, 3, 10, 11, 13
Camino 4: 1, 2, 3, 4, 5, 8, 9, 2, 10, 12, 13
Camino 5: 1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 13
Camino 6: 1, 2, 10, 12, 13
Veamos los posibles casos de prueba que se pueden generar para probar estos caminos.
N.Juristo/A. Moreno
Pg.107
Nmero de
Camino
1
Caso de Prueba
valor = [0, -999]
minimo = 0
mximo = cualquier entero
Objetivo
Probar el clculo de la
media pasando 100
veces por el ciclo y
proporcionando
101
valores de entrada o
ms
valor = -999
minimo = cualquier entero
mximo = cualquier entero
Resultado Esperado
media de los
primeros valores
100
total.entrada=100
total.valido =100
Inicialmente el camino 1 podra conducir a un caso de prueba sencillo en el que se pasara una sola
vez por el bucle (este es el primero que se ha indicado). Sin embargo, dada la restriccin del camino
3, este caso de prueba se puede ampliar para pasar 100 veces por el bucle y observar la reaccin del
sistema ante el dato 101.
Los casos de prueba 4 y 5 podran modificarse para que se pasara un nmero n de veces por el bucle
siendo la vez n+1 la que presentara el problema del valor menor que el mnimo o mayor que el
mximo respectivamente.
N.Juristo/A. Moreno
Pg.108
N.Juristo/A. Moreno
Pg.109
Considrese una aplicacin bancaria, donde el usuario puede conectarse al banco por Internet y
realizar una serie de operaciones bancarias. Una vez accedido al banco con las consiguientes
medidas de seguridad (clave de acceso y dems), la informacin de entrada del procedimiento que
gestiona las operaciones concretas a realizar por el usuario requiere la siguiente entrada:
-
Cdigo del banco. En blanco o nmero de tres dgitos. En este ltimo caso, el primero de
los tiene que ser mayor que 1.
Clave personal. Valor alfanumrico de cinco posiciones. Este valor se introducir segn la
orden que se desee realizar.
Orden. Puede estar en blanco o ser una de las dos cadenas siguientes:
o
Talonario
Movimientos
Tipo
Condicin de
Entrada
Clase Equivalencia No
Vlida
Cdigo banco
Cdigo
sucursal
Rango
N Cuenta
Valor
Clave
N.Juristo/A. Moreno
Valor
Pg.110
Orden
Conjunto,
con 15:
comportamiento
16: Talonario
distinto
17: Movimientos
Para generar los casos de prueba, consideremos la tcnica de Anlisis de Valores Lmite. Esta
tcnica conduce a que para determinadas clases de equivalencia se genere ms de un caso de
prueba. Este es el caso por ejemplo, de la clases de equivalencia 2 y 6 que representan un rango de
valores y para los que la tcnica de Anlisis de Valores Lmite indica que se generen dos casos de
prueba con el lmite inferior y el superior del rango respectivamente (para identificar estos casos de
prueba se ha aadido el sufijo a y b a las clases de equivalencia correspondientes).
Los casos de prueba resultantes se muestran a continuacin.
N
Caso
Clase de
equivalencia
Banco
Sucursal
Cuenta
Clave
Orden
Resultado
1, 6a, 9a,
12a, 15
1000
00000
00000
Todos los
movimientos
y talonario
100
9999
99999
zzzzz
Talonario
Envo de
talonario
2b, 6, 9, 12,
17
999
1001
12345
Hyu56
Movimientos
Envi de
movimientos
3, 6, 9, 12,
15
30A
1989
12347
Kuh98
Cdigo
banco
errneo
4, 6, 9, 12,
15
99
1989
12347
Kuh98
Cdigo
banco
errneo
5, 6, 9, 12,
15
1000
1989
12347
Kuh98
Cdigo
banco
errneo
1, 6, 7, 9, 12,
16
999
12347
Kuh98
Cdigo
sucursal
errneo
1, 6, 8, 9, 12,
16
10000
12345
Hyu56
Movimientos
Cdigo
sucursal
errneo
1, 6, 10, 12,
16
2345
9999
Jkgy5
Movimientos
Nmero
cuenta
errneo
N.Juristo/A. Moreno
Pg.111
10
1, 6, 11, 12,
16
7863
100000
Jkgy5
Movimientos
Nmero
cuenta
errneo
11
1, 6, 9, 13,
16
6754
89765
Jut8
Movimientos
Clave
errnea
12
1, 6, 9, 14,
16
9998
89765
Jut890
Movimientos
Clave
errnea
13
1, 6, 9, 12,
18
8765
89765
Ghy78
988
Orden
errnea
14
1, 6, 9, 12,
19
7654
89765
Ghy78
Talonarios
Orden
errnea
15
1, 6, 9, 12,
20
8769
89765
Ghy78
Movimiento
Orden
errnea
N.Juristo/A. Moreno
Pg.112
Ntese que este es el mismo programa que se utiliz en la parte de evaluacin estitica.
Especificacin del programa tokens
Nombre
tokens ordena/cuenta tokens alfanumricos
Uso
tokens [-ai] [-c chars] [-m cuenta]
Descripcin
tokens lee de la entrada estndar, cuenta todos los tokens alfanumricos que aparecen e imprime el
nmero de veces que aparecen, siguiendo un orden lexicogrfico ascendente.
Opciones
-m cuenta: Indica el nmero mnimo de veces que han de aparecer los tokens en la
entrada para que aparezca en la salida.
Ver tambin
wc(1), sort(1), uniq(1).
N.Juristo/A. Moreno
Pg.113
N.Juristo/A. Moreno
Pg.114
}
char *
getword(ioptr) FILE *ioptr;
{
static char string[1024];
char *ptr = string;
register int c;
assert(ioptr != NULL);
for (;;)
{
c = getc(ioptr);
if (c == EOF)
if (ptr == string)
return(NULL);
else
break;
if (!MapAllowed[c])
if (ptr == string)
continue;
else
break;
*ptr++ = MapAllowed[c];
}
*ptr = '\0';
return(string);
}
void tokens(ioptr) FILE *ioptr;
{
TNODE *root = NULL;
char *s;
assert(ioptr != NULL);
while (s = getword(ioptr))
root = install(s, root);
treeprint(root);
}
int main(argc, argv) int argc; char ** argv;
{
int c, errcnt = 0;
extern char *optarg;
while ((c = getopt(argc, argv, "ac:im:")) != EOF)
switch(c)
{
case 'a': Alpha = 0; break;
case 'c':
while (*optarg)
{
MapAllowed[*optarg] = *optarg;
optarg++;
}
break;
case 'i': Ignore = 1; break;
case 'm': Mincount = atoi(optarg); break;
default: errcnt++;
N.Juristo/A. Moreno
Pg.115
}
if (errcnt)
{
fprintf(stderr, "Usage: %s [-i] [-c chars] [-m count]\n", *argv);
return(1);
}
for (c = 'a'; c <= 'z'; c++)
MapAllowed[c] = c;
for (c = 'A'; c <= 'Z'; c++)
MapAllowed[c] = Ignore ? c - 'A' + 'a' : c;
if (!Alpha)
for (c = '0'; c <= '9'; c++)
MapAllowed[c] = c;
tokens(stdin);
return(0);
}
N.Juristo/A. Moreno
Pg.116
Ntese que este ejercicio se utiliz tambin para las tecnicas estticas.
Especificacin del programa series
Nombre
series genera series numricas aditivas.
Uso
series comienzo fin [cadencia]
Descripcin
series imprime los nmeros reales comprendidos entre comienzo y fin, con el formato de uno por
lnea. series empieza por comienzo, al que suma o resta sucesivamente, segn corresponda, la
cadencia, para acercarse, posiblemente llegar a, pero nunca pasar el fin.
Si todos los argumentos son nmeros enteros, slo se generan nmeros enteros en la salida. La
cadencia debe ser un nmero distinto de cero; si no se especifica, se asume que es de tamao
unitario (1). En el resto de los casos, series imprime el mensaje de error correspondiente.
Ejemplo
Para contar de 1 a 100:
series 1 100
Para hacer lo mismo pero al revs:
series 100 1
Limitaciones
El nmero de dgitos significativos reportados est limitado. Si el ratio del rango de la series entre la
cadencia es demasiado grande, aparecern varios nmeros iguales.
N.Juristo/A. Moreno
Pg.117
La longitud mxima de una serie est limitada al tamao del mximo entero largo que pueda ser
representado en la mquina que est siendo usada. Si se excediese este valor, el resultado es
impredecible.
N.Juristo/A. Moreno
Pg.118
Consultar la hoja suplementaria para aplicar la tcnica Revisin de Cdigo con el Programa X a
medida que se leen las instrucciones
Consultar la hoja suplementaria para aplicar la tcnica Revisin de Cdigo con el Programa X a
medida que se leen las instrucciones
Lectura del cdigo
2. Pone el nombre en el Formulario de abstracciones (E12) y en el de recogida de datos (E11).
3. Lee por encima el cdigo para tener una idea general del componente. Si te parece
descubrir faltas mientras haces este paso o alguno de los dos siguientes, mrcalas. No
obstante, no pierdas demasiado tiempo en hacer un anlisis preciso de ellas.
4. Determina las dependencias entre las funciones individuales del cdigo fuente, usando para
ello un rbol de llamadas. Normalmente las funciones ya estarn ordenadas en el cdigo, de
tal modo que las funciones de bajo nivel (hojas) estn al comienzo y las funciones de ms
alto nivel (raz) aparecen al final. Comienza aplicando la tcnica de revisin de cdigo con
las funciones hoja y sigue hacia la raz.
5. Intenta entender la estructura de cada funcin individual identificando las estructuras
elementales (secuencias condicionales, bucles) y marcndolas. Combina las estructuras
elementales para formar estructuras ms grandes hasta que hayas entendido la funcin
entera.
6. Trata de determinar el significado de cada estructura comenzando con la ms interna y
anota el resultado en el formulario para tal propsito (E12). Usa nmeros de lnea (lnea xy) cuando hagas eso. Evita utilizar conocimiento implcito que no resida en la estructura,
por ejemplo valores iniciales, entradas o valores de parmetros. Describe las partes lo ms
funcionalmente posible. Mientras hagas eso, usa principios generalmente aceptados del
dominio de aplicacin para mantener la descripcin breve y entendible. Por ejemplo, en el
caso de bsqueda en un rbol, menciona bsqueda en profundidad en lugar de describir lo
que hace la bsqueda en profundidad.
N.Juristo/A. Moreno
Pg.119
Bsqueda de inconsistencias
8. Recoge el Formulario para inconsistencias (E13) y la especificacin del cdigo (E01). Pon
el nombre al Formulario para inconsistencias.
9. Lee con detenimiento la especificacin que se te ha entregado. Dicha especificacin
describe el componente como un todo, no las funciones individuales. Detecta las posibles
inconsistencias comparando la especificacin con tu descripcin del componente. Escribe
las inconsistencias que hayas detectado en el formulario E13.
Para ello, numera las inconsistencias que hayas encontrado desde 1 hasta n en la columna
denominada N Inc (nmero de inconsistencia) del formulario para inconsistencias.
Describe la inconsistencia en las columnas a la derecha del nmero de inconsistencia.
10. Una vez creas que has detectado todas las inconsistencias, entrega todo el material a la
persona a cargo del experimento. Ya has terminado.
N.Juristo/A. Moreno
Pg.120
Identificador:
Nombre Alumno
Antes de comenzar...
1. Cul es tu experiencia con el lenguaje de programacin C?
Experiencia (relativa). Marca la escala apropiadamente. Las marcas entre cajas son vlidas.
Estimacin
Comparacin
ninguna
conozco la
teora
pequeos
ejercicios
usado en
prcticas
usado en un
desarrollo
experto
Resultados
Para cada entrada referida al tiempo que ha transcurrido, deduce el tiempo que hayas tomado para
descansos, etc.
3. A qu hora comenzaste el ejercicio de revisin de cdigo? (hora:minutos)
4. Cunto tiempo necesitaste para construir las abstracciones? (horas:minutos)
5. Cuntos niveles de abstracciones has generado?
6. A qu hora comenzaste a buscar las inconsistencias? (hora:minutos)
7. Cunto tiempo necesitaste para encontrar las inconsistencias? (horas:minutos)
8. A qu hora terminaste el experimento? (hora:minutos)
9. Podras asegurar que encontraste todos los fallos? Estima el porcentaje de fallos que has
encontrado (en %)
10. Cmo de bien crees que has efectuado la revisin de cdigo? Marca la escala
apropiadamente.
Estimacin
Comparacin
N.Juristo/A. Moreno
fatal
bastante mal
regular
bien
muy bien
perfectamente
Pg.121
Identificador:
Nombre Alumno 1
Abstracciones
Lneas
N.Juristo/A. Moreno
Abstraccin
Pg.122
Identificador:
Nombre Alumno 1
Inconsistencias detectadas
N
Inc.
Comportamiento esperado
N.Juristo/A. Moreno
Pg.123
Criterio de Cobertura
Obtener cobertura de decisiones (y de sentencias) significa que cada rama en un componente se
ha ejecutado al menos una vez. Las ramas en los programas escritos en C las crean las
sentencias: if, , for, while y do-while. Cada una de estas sentencias genera dos
decisiones (ramas); la evaluacin de la expresin de la decisin debe tomar valores verdadero y
falso al menos una vez.
Las ramas tambin las puede crear la construccin switch-case. Para probar todas las
ramas, se deben ejecutar todas las etiquetas case al menos una vez. Esto incluye la etiqueta
default, incluso si no est escrita explcitamente en el cdigo fuente. Cada etiqueta case
genera una decisin nica.
N.Juristo/A. Moreno
Pg.124
Identificador:
Nombre Alumno
Antes de comenzar...
1. Cul es tu experiencia con el lenguaje de programacin C?
Experiencia (relativa). Marca la escala apropiadamente. Las marcas entre cajas son
vlidas.
Estimacin
Comparacin
ninguna
conozco la
teora
pequeos
ejercicios
usado en
prcticas
usado en un
desarrollo
experto
Resultados
Para cada entrada referida al tiempo que ha transcurrido, deduce el tiempo que hayas tomado
para descansos, etc.
1. A qu hora comenzaste el ejercicio de prueba estructural? (hora:minutos)
2. Cunto tiempo necesitaste para elaborar los casos de prueba? (horas:minutos)
3. Cuntos casos de prueba generaste?
4. Cmo de bien crees que has efectuado la prueba estructural? Marca la escala
apropiadamente.
Estimacin
Comparacin
N.Juristo/A. Moreno
fatal
bastante mal
regular
bien
muy bien
perfectamente
Pg.125
Identificador:
Nombre Alumno
N de
caso
N.Juristo/A. Moreno
Datos de prueba
Pg.126
N.Juristo/A. Moreno
Pg.127
Identificador:
Nombre Alumno
Antes de comenzar...
1. Cul es tu experiencia con el lenguaje de programacin C?
Experiencia (relativa). Marca la escala apropiadamente. Las marcas entre cajas son vlidas.
Estimacin
Comparacin
Ninguna
conozco la
teora
pequeos
ejercicios
usado en
prcticas
usado en un
desarrollo
experto
3. Procedencia (escuela/Facultad):
Resultados
Para cada entrada referida al tiempo que ha transcurrido, deduce el tiempo que hayas tomado para
descansos, etc.
1. A qu hora comenzaste el ejercicio de pruebas funcionales? (hora:minutos)
2. Cuntas clases de equivalencia generaste?
3. Cuntos casos de prueba generaste?
4. Cunto tiempo necesitaste para generar los casos de prueba? (horas:minutos)
5. Cmo de bien crees que has efectuado las pruebas funcionales? Marca la escala
apropiadamente.
Estimacin
Comparacin
N.Juristo/A. Moreno
fatal
bastante mal
regular
bien
muy bien
perfectamente
Pg.128
Identificador:
Nombre Alumno
Clases de Equivalencia
Nmero
N.Juristo/A. Moreno
Descripcin
Pg.129
Identificador:
Nombre Alumno
N de N Clase Equival.
caso
Datos de prueba
130
131