La prueba de software, los métodos formales y los computer languages
Upcoming SlideShare
Loading in...5
×
 

La prueba de software, los métodos formales y los computer languages

on

  • 165 views

A lo largo de la relativamente corta historia de la ingeniería de software se han desarrollado varios enfoques para elevar la calidad de productos de software. En esta sesión se abordarán dos de ...

A lo largo de la relativamente corta historia de la ingeniería de software se han desarrollado varios enfoques para elevar la calidad de productos de software. En esta sesión se abordarán dos de ellos, la prueba de software y los métodos formales: se mostrarán los alcances algorítmicos de la prueba de software y las estrategias heurísticas creadas para superarlos; se mostrará un ejemplo de un método formal, sus aplicaciones y alcances.
Al comparar y vincular ambos enfoques confluiremos en el concepto de computer language, una de las formas con mayor valor agregado de empaquetar conocimiento y experiencia que puede ser útil para muchas organizaciones desarrolladoras de software. Pero como veremos, los computer languages son también un mecanismo que nos permite elevar la productividad y efectividad de la prueba de software.

Semblanza del conferencista:
Luis Vinicio León es Director General de e-Quallity, corporativo especializado en prueba de software.

Luis Vinicio fue profesor-investigador en la universidad jesuita ITESO durante 15 años, que incluyeron una estancia doctoral en Alemania dedicada a la investigación de prueba de software. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos relacionados con la prueba de software.

Desde e-Quallity, Luis Vinicio ha dirigido proyectos de mejora de procesos de prueba que han conducido a la certificación internacional de varias organizaciones, así como proyectos de investigación aplicada que han incrementado significativamente la competitividad de algunas empresas de prueba.

Statistics

Views

Total Views
165
Views on SlideShare
164
Embed Views
1

Actions

Likes
0
Downloads
8
Comments
0

1 Embed 1

http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

La prueba de software, los métodos formales y los computer languages La prueba de software, los métodos formales y los computer languages Presentation Transcript

  • “…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
  • 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
  • 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
  • 3. Exigencia en la calidad Critical systems Globalización y educación de los clientes Crisis del Software: Problemática
  • 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
  • 3. Exigencia en la calidad  Total Quality Management for software  Mejora de procesos (CMMI,MoProSoft,etc.)  Prueba de Software Crisis del Software: Soluciones
  • 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?
  • Modelo-V
  • 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)
  • 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
  • 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
  • Alcances teóricos: no-decidible (Hk), pero automatizable en algunos aspectos semidecidibles P Testing NP no-decidibles Alcances de la Prueba de Software
  • 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
  • Calidad de Sw, ISO 25000 y Medi- ción Grande? Objetiva? Coexistencia?
  • 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
  • Requisitos formales Diseño formal Código fuente Lx Ly Lz 3.Métodos formales: Planteamiento
  • 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
  • • “Demasiado matemáticos” y difíciles de aprender • Con pocas herramientas que los soporten • Limitados a pocos dominios de aplicación Mitos y Aplicaciones
  • Generación automática de Parsers a partir de Grafos de Sintaxis Un Ejemplo
  • 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
  • Diseño formal Código fuente L2 = Grafos de Sintaxis L3 = Pseudo código En este caso…
  • 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
  • • 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
  • t NN G1 Gn ... G1 Gn G1 G2 ... ... a) e) d) b) c) f) G1 Name g) L2 : Grafos de Sintaxis
  • Ejercicio
  • 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
  • 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
  • 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(); } }
  • 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
  • LIT número LOD variable STO dirección JMP dirección JMC dirección OPN +|-|*|/|=||… El Conjunto de Instrucciones
  • 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
  • • 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
  • • 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
  • • 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
  • “…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