Martin Pol afirma que Polteq es difícil de igualar en el mundo en términos de resultados comparables de evaluación. Solo compañías en industrias de alto riesgo, como la farmacéutica, defensa y aviación, logran puntuaciones más altas.

1. “…A testing company with comparable assessment results is hard to
find in the world. Only companies in high-risk industries, e.g.
pharmaceutics, defense and aviation, achieve higher scores”.
Martin Pol
Polteq, 2008

2. Agenda
1. “Crisis del Software”
• Problemática y Soluciones planteadas
2. Prueba de Software
• Definición y Alcances
3. Métodos formales
• Planteamiento general y Ejemplo
4. Lenguajes de Computación
• Clases y Tipos
5. La Utilidad de esto para tu empresa
• Cuestionamientos

3. 1. Incremento en la demanda
Legacy systems; embedded software
Cada vez más áreas de aplicación
2. Incremento en la complejidad
Sistemas de software+firmware+
hardware
Tamaño
1.Crisis del Software: Problemática

4. 3. Exigencia en la calidad
Critical systems
Globalización y educación de los clientes
Crisis del Software: Problemática

5. 1. Incremento en la demanda
Herramientas y capacitación para
técnicos y no-técnicos
Re-Uso de software
2. Incremento en la complejidad
Ambientes de desarrollo (CASE Systems)
Lenguajes de computación
Metodologías
Crisis del Software: Soluciones

6. 3. Exigencia en la calidad
 Total Quality Management for software
 Mejora de procesos (CMMI,MoProSoft,etc.)
 Prueba de Software
Crisis del Software: Soluciones

7. Inicialmente confundida con debugging y
conceptualizada para ganar confianza.
Myers: el objetivo es detectar errores.
Una definición:
Proceso paralelo al de desarrollo para
determinar si el producto alcanza el nivel de
calidad acordado.
Con apoyo de herramientas (CAST) se
ejercita el sistema a probar (SUT)
aplicándole estímulos (TCs) diseñados con
métodos ingenieriles para detectar
insatisfacción de requerimientos.
2.Qué es la Prueba de Software?

8. Modelo-V

9. 1.Establecer alcances,
criterios de éxito y
entregables
2.Estimar del Esfuerzo del
Prueba
3.Planear el Proyecto
4.Reproducir el contexto
del SUT
5.Realizar las Pruebas
6. Obtener métricas y dar
resultados
7. Administrar Anomalías
8.Cerrar
Proceso de Prueba (Nivel 1)

10. e1
e2
e3
isóceles
equilátero
escaleno
no es triángulo
Cuántos Casos de Prueba?
Cuántos recursos para probar?
Automatizados?
Un Ejemplo clásico

11. Alcances prácticos:
 Cantidad de posibilidades inmanejable [Trg]
 La organización que desarrolla no debe
probar
 Barrera de la complejidad: la complejidad
del software (y por lo tanto la de los
errores) crece hasta los límites de nuestra
habilidad para manipular esa complejidad
Alcances de la Prueba de Software

12. Alcances teóricos: no-decidible (Hk),
pero automatizable en algunos aspectos
semidecidibles
P
Testing
NP
no-decidibles
Alcances de la Prueba de Software

13. Con recursos y tiempo limitados,
detectar
la mayor cantidad de defectos,
lo más nocivo posible,
lo antes posible
Objetivo de la Prueba de Software

14. Calidad
de Sw,
ISO
25000
y
Medi-
ción
Grande? Objetiva? Coexistencia?

15. 3. Exigencia en la calidad
 Total Quality Management for software
 Mejora de procesos (CMMI,MoProSoft,etc.)
 Prueba de Software
 Métodos Formales
Crisis del Software: Soluciones

16. Requisitos
formales
Diseño
formal
Código
fuente
Lx
Ly
Lz
3.Métodos formales: Planteamiento

17. N  
N  t | t1 N1
1 N 2  1  2
L3
L2
L1
Le
L0
Lg
LR
LL
Type Name Rules Examples
Regular
Context
sensitive
Decidable/
Recursive
Phrase
structure/
General
Context
free
  
ai bj ck dm i,j,k,m
independent
  , ||  ||
ak bk2 cn dn-1
an bn cn
an bn  an b2n
Regular
Expressions
Syntax
Graphs
None (it’s impossible)
Lf
Finite an bn , K1 n K2
ak bn cn d k
an bn, 0 n
(det)
ak bn ck dn
a
1st Order Pre-
dicate Calculus
{M | L(M) Le }
L={}, LL3,2
n2
?
Recursively
enumerable
Computer Lgs
Natural Lgs
Jerar-
quía
de
Chom
sky

18. • “Demasiado matemáticos” y difíciles
de aprender
• Con pocas herramientas que los
soporten
• Limitados a pocos dominios de
aplicación
Mitos y Aplicaciones

19. Generación automática
de Parsers a partir de
Grafos de Sintaxis
Un Ejemplo

20. Constitución de un Compilador
Analizador léxico
(scanner)
Analizador sintáctico
(parser)
Analizador
semántico
Manejador
de Errores
Generador
de Código
Brincar
caracteres
irrelevantes
Identificar
cadenas
relevantes
Verificar orden
correcto de cadenas
Validar significado
Ignorar errores
Generar código
token
lexema

21. Diseño
formal
Código
fuente
L2 =
Grafos
de
Sintaxis
L3 =
Pseudo
código
En este caso…

22. N  
N  t | t1 N1
1 N 2  1  2
L3
L2
L1
Le
L0
Lg
LR
LL
Type Name Rules Examples
Regular
Context
sensitive
Decidable/
Recursive
Phrase
structure/
General
Context
free
  
ai bj ck dm i,j,k,m
independent
  , ||  ||
ak bk2 cn dn-1
an bn cn
an bn  an b2n
Regular
Expressions
Syntax
Graphs
None (it’s impossible)
Lf
Finite an bn , K1 n K2
ak bn cn d k
an bn, 0 n
(det)
ak bn ck dn
a
1st Order Pre-
dicate Calculus
{M | L(M) Le }
L={}, LL3,2
n2
?
Recursively
enumerable
Computer Lgs
Natural Lgs
LL
Jerar-
quía
de
Chom
sky

23. • De Especificación
• De Diseño
• De Documentación
• De Definición de
Procesos
• De Programación
La Torre de
Babel de la
Computación?

4. Lenguajes de Computación

24. t
NN
G1 Gn
...
G1
Gn
G1
G2
... ...
a)
e)
d)
b)
c)
f)
G1
Name
g)
L2 : Grafos de Sintaxis

25. Ejercicio

26. t
NN
C ( ) =
) =
) =
C (
C (
;
if (token == t)
token = scan();
else
err_msg();
N();
G1C (
Name
) = Name() {
C(G1)
};
a)
b)
c)
g)
L3 : Pseudocódigo

27. G1 Gn
...C ( ) = { C(G1)
C ( ) = C(G1)
d)
f)
...
C(Gn) }
C ( ) =G1
Gn
... ...
e)
...
default: err_msg();}
switch(token){
in first(Gn): C(Gn)
in first(G1): C(G1)
while(token in first(G2)){
C(G2)
C(G1) }
G1
G2
L3 : Pseudocódigo

28. XPN () {
SUM();
while tok in first({‘+’}) {
if tok == ‘+’
tok = scan();
else err_msg();
SUM();
}
}
El Programa generado
SUM() {
FAC();
while tok in first(‘*’}) {
if tok == ‘*’
tok = scan();
else err_msg();
FAC();
}
}

29. FACT () {
suitch (tok)
in first(Id): if tok == Id tok=scan();
else err_msg();
in first(Nr): if tok == Nr tok=scan();
else err_msg();
in first(‘(‘):{ if tok == ‘(’ tok=scan();
else err_msg();
XPN();
if tok == ‘)’ tok=scan();
else err_msg(); }
default: err_msg();
}
El Programa generado

30. LIT número
LOD variable
STO dirección
JMP dirección
JMC dirección
OPN +|-|*|/|=||…
El Conjunto de Instrucciones

31. LOD A
LOD B
LIT 3
OPN /
OPN +
LIT 10
OPN 
JMZ L1
LOD B
LIT 1
OPN +
STO A
JMP L2
LIT 5
STO B
…A+B/310
( C)
L1:
L2:
IF C A := B+1;
ELSE B := 5; ...
En la otra Dirección: Patrones

32. • Se decía que con FORTRAN se hacía
“programación automática”
• Se argüía que los programas en FORTRAN
eran muy ineficientes
Al inicio…
• La generación de código era masiva, lo cual
incrementaba significativamente la
productividad
• La generación de código era libre de
errores, lo cual decrementaba la cantidad de
defectos
Pero…
Antiguos detractores

33. • Tienen sistematizado o formalizado
(partes de) su proceso de desarrollo?
• Cuáles son sus patrones?
• Podríamos utilizarlos para ayudarles a
generar código?
Preguntas clave

34. • Compilers: Aho, Sethi, Ullman;
Addison-Wesley
• Artículo “Software’s chronic Crisis”:
http://www.di.ufpe.br/~java/graduacao/refere
ncias/SciAmSept1994.html
• Formal Methods: hay una gran cantidad
de información en el web; algunos links
útiles son
http://www.fmeurope.org/
http://en.wikipedia.org/wiki/Formal_method
s #Formal_methods_and_notations
Un poco de Bibliografía

35. “…A testing company with comparable assessment results is hard to
find in the world. Only companies in high-risk industries, e.g.
pharmaceutics, defense and aviation, achieve higher scores”.
Martin Pol
Polteq, 2008