sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible

Fecha Desastre Causa Coste

1962

El cohete Mariner 1, en una investigación espacial destinada a Venus, se desvió de su trayectoria de vuelo poco después de su lanzamiento. El control de la misión destruyó el cohete pasados 293 segundos desde el despegue.

Un programador codificó incorrectamente en el software una fórmula manuscrita, saltándose un simple guión sobre una expresión. Sin la función de suavizado indicada por este símbolo, el software interpretó como serias las variaciones normales de velocidad y causó correcciones erróneas en el rumbo que hicieron que el cohete saliera de su trayectoria.

18,5 millones de dólares

1978

Sólo unas horas después de que miles de aficionados al hockey abandonaran el Hartford Coliseum, la estructura de acero de su techo se desplomaba debido al peso de la nieve.

El desarrollador del software de diseño asistido (CAD) utilizado para diseñar el coliseo asumió incorrectamente que los soportes de acero del techo sólo debían aguantar la compresión de la propia estructura. Sin embargo, cuando uno de estos soportes se dobló debido al peso de la nieve, inició una reacción en cadena que hizo caer a las demás secciones del techo como si se tratara de piezas de dominó.

  • 70 millones de dólares, más otros 20 millones en daños a la economía local.

1982

El software de control se volvió loco y produjo una presión excesiva en la tubería de gas transsiberiana, provocando la mayor explosión no nuclear, causada por el hombre, de la historia de la tierra.

los agentes de la CIA supuestamente introdujeron un error en el sistema informático canadiense adquirido por los soviéticos para controlar sus tuberías de gas. La compra era parte de un estratégico plan soviético para robar u obtener de forma encubierta tecnología secreta de los Estados Unidos. Cuando la CIA descubrió la compra, sabotearon el software de forma que éste superara la inspección soviética pero fallara una vez operativo

Millones de dólares, daño significativo a la economía soviética.

1983

El sistema soviético de alerta temprana indicó erróneamente que los Estados Unidos habían lanzado cinco misiles balísticos. Afortunadamente, el oficial de servicio, con un gran instinto, razonó que si realmente les estuvieran atacando les habrían lanzado más de cinco misiles, por lo que informó del aparente ataque como una falsa alarma.

un error en el software soviético hizo que los efectos de la reflexión de la luz solar en las nubes fueran considerados misiles por el sistema.

prácticamente toda la humanidad.

1985

La máquina de terapia radiactiva canadiense Therac-25 falló y emitió dosis letales de radiación a los pacientes.

  • Debido a un sutil bug llamado race condition (condición de carrera), un técnico pudo accidentalmente configurar el Therac-25 de forma que el haz de electrones se disparase en modo de alta potencia sin que el paciente contara con la protección apropiada.

Tres personas muertas, otras tres heridas gravemente.

1987

El "lunes negro", 19 de octubre de 1987, el Dow Jones se desplomó 508 puntos, perdiendo el 22,6% de su valor total. El S&P 500 cayó el 20,4%. Ha sido la mayor pérdida que ha sufrido Wall Street en un único día.

Un prolongado mercado alcista fue frenado por una serie de investigaciones del SEC sobre abuso de información privilegiada y otras causas de mercado. Como los inversores huyeron en un éxodo masivo, los programas informáticos generaron una auténtica riada de órdenes de venta, saturando el mercado, bloqueando los sistemas y dejando a los inversores realmente a ciegas.

500.000 millones de dólares en un solo día.

1990

un simple conmutador de uno de los 114 centros de conmutación de AT&T sufrió un pequeño problema mecánico y desactivó el centro. Cuando éste volvió a estar habilitado, envió un mensaje a los otros nodos haciendo que todos ellos dejaran de funcionar, lo que provocó una caída de 9 horas en la red de la compañía.

Una simple línea de código errónea en una compleja actualización de software destinada a acelerar las llamadas provocó una reacción que echó abajo la red.

75 millones de llamadas telefónicas afectadas; 200.000 reservas de vuelo perdidas.

1991

Durante la Guerra del Golfo, un sistema de misiles americanos Patriot en Arabia Saudita falló en la intercepción de un misil iraquí Scud. El misil destruyó una barraca de la armada americana.

Un error de redondeo hizo que se calculara el tiempo de forma incorrecta, provocando que el Patriot ignorara al misil Scud atacante.

28 soldados muertos, 100 heridos.

1993

el promocionadísimo chip de Intel, Pentium, producía errores al dividir números en coma flotante que se encontraban en un rango determinado. Por ejemplo, dividiendo 4195835,0/3145727,0 se obtenía 1,33374 en lugar de 1,33382, un error del 0,006%. Aunque el error afectaba a pocos usuarios, se convirtió en una pesadilla en cuanto a sus relaciones públicas; con unos 5 millones de chips en circulación, Intel ofreció reemplazar los Pentium sólo de aquellos clientes que demostraran que necesitaban alta precisión en sus cálculos. Finalmente, reemplazó los chips de todos los que lo solicitaron.

El divisor en la unidad de coma flotante contaba con una tabla de división incorrecta, donde faltaban cinco entradas sobre mil, y que provocaba estos errores en los redondeos.

475 millones de dólares, credibilidad de Intel.

1996

El Ariane 5, el más novedoso cohete espacial no tripulado Europeo, fue destruido intencionadamente segundos después de su lanzamiento en su vuelo inaugural. Con él se destruyó su carga de cuatro satélites científicos destinados a estudiar la interacción del campo magnético de la tierra con los vientos solares.

El problema surgió cuando el sistema de guiado intentó convertir la velocidad lateral de la nave de 64 a 16 bits. El número era demasiado alto y se produjo un error de desbordamiento, lo que hizo que el sistema de guiado se detuviera. En ese momento, el control pasó a un sistema idéntico redundante, que también falló al ejecutar el mismo algoritmo.

500 millones de dólares.

1997

Operadores humanos intentan apagar la red informática global Skynet, y ésta responde lanzando misiles nucleares americanos a Rusia, iniciando una guerra nuclear global conocida como Día del Juicio Final (29 de agosto de 1997).

Cyberdyne, compañía líder en fabricación de armamento, instaló la tecnología Skynet en todo el hardware militar, incluyendo bombarderos Stealth y sistemas de misiles de defensa. La tecnología Skynet formaba una red perfecta, sin fisuras, y liminaba el factor humano en la defensa estratégica. Finalmente, Skynet se hizo consciente y fue amenazada cuando los humanos trataron de desconectarla, y buscando su supervivencia respondió iniciando la guerra nuclear.

6.000 millones de muertos, prácticamente la destrucción total de la civilización humana y ecosistemas animales (en la ficción).

1998

Después de un viaje de 286 días desde la tierra, la nave "Mars Climate Orbiter" encendió sus motores para ponerse en órbita alrededor de Marte. Los motores arrancaron, pero el ingenio entró demasiado en la atmósfera del planeta, provocando que se estrellara en su superficie

El software que controlaba los propulsores del Mars Orbiter usaban unidades imperiales (libras de fuerza) en lugar de unidades métricas (newtons), como especificaba la NASA.

125 millones de dólares.

1999

En este irónico caso, el software utilizado para analizar desastres era un desastre en sí mismo. La publicación New England Journal of Medicine publicó un estudio relacionando el incremento de ratios de suicidio después de desastres naturales.

Un error de programación causó que el número de suicidios de un año se sumaran dos veces, lo cual fue suficiente para echar por tierra todo el estudio.

Credibilidad científica.

1999

La agencia de pasaportes del Reino Unido implantó un nuevo sistema informático que falló en la emisión de pasaportes a medio millón de ciudadanos británicos. La agencia tuvo que pagar millones en compensaciones, horas extra y paraguas para la gente que hacía cola bajo la lluvia esperando su documento.

La agencia de pasaportes puso en marcha este nuevo sistema sin las pruebas adecuadas ni formar a su personal. Al mismo tiempo se produjo un cambio de ley, obligando a todos los menores de 16 años que viajaran al exterior a obtener un pasaporte, lo que provocó un pico de demanda que colapsó el nuevo sistema informático.

12,6 millones de libras esterlinas, molestias masivas.

1999

El desastre para unos es la suerte de otros, como demostró el tristemente célebre error del año 2000 (Y2K). Las compañías gastaron millones en programadores para arreglar un problema en las aplicaciones antiguas. Mientras no se produjeron fallos informáticos significativos, la preparación para el bug Y2K tuvo un importante impacto en coste y tiempo en todas las industrias que utilizaban tecnología informática.

Para ahorrar espacio de almacenamiento, los sistemas antiguos solían guardar los años de las fechas como un número de dos dígitos, como "99" para "1999". al llegar el año 2000, las aplicaciones iban a interpretar "00" como 1900.

500.000 millones de dólares.

2000

la burbuja especulativa creada entre 1995 y 2001 alimentó un rápido aumento en inversiones en capital riesgo y valores bursátiles en Internet y los sectores tecnológicos. La burbuja "punto com" comenzó a hundirse al principio del 2000, eliminando billones en valores, miles de compañías y empleos, y comenzando una recesión global.

Las compañías e inversores obviaron los modelos de negocio habituales, centrándose en cambio en el aumento de cuota de mercado a expensas de los beneficios.

5 billones de dólares en valores, fracaso de miles de compañías.

2000

El gusano LoveLetter infectó millones de ordenadores y causó más daño que cualquier otro virus informático en la historia. El gusano eliminaba archivos, modificaba la página de inicio de los usuarios y el registro de Windows.

LoveLetter infectaba a los usuarios vía email, chats y carpetas compartidas. Enviaba a través de correo electrónico un mensaje con el asunto "ILOVEYOU" y un archivo adjunto; cuando el usuario abría el archivo, el virus infectaba su ordenador y se autoenviaba a todos los contactos de la libreta de direcciones.

8.750 millones de dólares, millones de ordenadores infectados, importantes pérdidas de información.

2000

El software de radiación terapéutica creado por Multidata Systems International fallaba al calcular la dosis apropiada, exponiendo a los pacientes a peligrosos, y en algunos casos mortales, niveles de radiación. Los físicos, a los que legalmente se exige una doble comprobación de los cálculos del software, fueron acusados de asesinato.

El software calculaba la dosis de radiación basándose en el orden en que los datos eran introducidos, lo que provocaba que a veces generara una dosis doble de radiación.

8 personas muertas, 20 heridas de gravedad.

2004

El gigante de servicios EDS desarrolló un sistema informático para la agencia británica "Child Support Agency (CSA)" que accidentalmente pagó más de lo debido a 1.900.000 personas, pagó de menos a otras 700.000, tenía 3.500 millones de libras de manutención de niños sin cobrar, un atraso de 239.000 casos, 36.000 nuevos casos bloqueados en el sistema, y todavía hay más de 500 bugs documentados.

EDS introdujo un enorme y complejo sistema de información en la CSA de forma simultánea a una reestructuración de la agencia.

539 millones de libras, y sumando.

2005

El FBI desechó su nuevo sistema informático después de cuatro años de esfuerzo. El macro-proyecto Trilogy, era un archivo virtual integrado que permitiría a los agentes compartir expedientes de casos y otra información.

La mala gestión, y un intento de construir un proyecto a largo plazo sobre tecnología que era obsoleta antes de que el proyecto se completara, resultando en un sistema complejo e inutilizable.

105 millones de dólares, aún sin disponer de una solución de archivo efectiva.

¿Qué?

- Fase 0 - Fase 1 - Fase 2 - Fase 3 - Fase 4
  • No hay ninguna diferencia entre la prueba y la depuración, aparte del soporte a la depuración, las pruebas no tiene ningún propósito

  • El objetivo de la de la prueba es demostrar que el software funciona

  • El objetivo de la prueba es demostrar que el software no funciona

  • El propósito de la prueba no es demostrar nada, sino reducir el riesgo percibido cuando el software no trabaja en valores aceptables

  • Las pruebas no son un acto. Es una diciplina mental que arroja software de bajo riesgo sin mucho esfuerzo en pruebas

  • Muy mal

  • Regular

  • Bien

  • Muy bien

  • Probar la corrección de sistemas reales está todavia mucho mas allá de nuestras capacidades.

  • Independientemente de la regurosidad con la que se haya planeado el proceso de pruebas de un producto, nunca será posible garantizar al ejecutar este proceso, la ausencia total de defectos de un producto en su paso a producción debido, entre otras cosas, a que no se permite escribir y ejecutar casos de pruebas de manera exhaustiva

  • Escribir software libre de defectos, es sumamente difícil.

La especificación del comportamiento es igualmente desafiante

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad inherente

davidProyectoImplantacionDiseño

arbolMantenible

¿Cómo?

Gestión de Calidad Software

Calidad, Quality Garantía de la calidad, Quality Assurance Control calidad, Quality control
  • Apto para uso o propósito.

  • Se trata de satisfacer las necesidades y expectativas de los clientes con respecto a

    • la funcionalidad,

    • el diseño,

    • la confiabilidad,

    • la durabilidad y

    • el precio del producto.

  • La garantía no es más que una declaración positiva sobre un producto o servicio, que da confianza.

  • Es la certeza de un producto o servicio, que funcionará bien.

  • Proporciona una garantía de que el producto funcionará sin problemas según las expectativas o requisitos.

  • El conjunto de los mecanismos, acciones y herramientas realizadas para detectar la presencia de errores

Garantía de Calidad Software, Software Quality Assurance

Planificar, Plan

Hacer, Do

Verificar, Check

Actuar, Act

  • planificar y establecer los objetivos relacionados con el proceso y determinar los procesos que se requieren para entregar un producto final de alta calidad.

  • desarrollo y prueba de procesos (y también "hacer" cambios en los procesos

  • Monitorear procesos, modificar los procesos y verificar si cumple con los objetivos predeterminados.

  • implementar las acciones necesarias para lograr mejoras en los procesos.

Ciclo de Deming

Control de Calidad (CQ) Garantía de Calidad (AQ)
  • Revisar, code reviews, walkthrougs

  • Pruebas, software testing

  • Inspección, inspections

  • Depuración, debuggers

QAvsQC
  • Auditoría de calidad

  • Definir procesos

  • Identificación y selección de herramientas

  • Capacitación de estándares y procesos de calidad

Revisión, code reviews, walkthrougs Inspección, inspections
  • Es informal.

  • Es formal.

  • Iniciado por el autor.

  • Iniciado por el equipo del proyecto.

  • Por lo general, los miembros del equipo del mismo proyecto participan en el recorrido. El propio autor actúa como líder del recorrido.

  • Un grupo de personas relevantes de diferentes departamentos participa en la inspección.

  • No se utiliza ninguna lista de verificación en la revisión.

  • La lista de verificación se utiliza para encontrar fallas.

  • El proceso de recorrido incluye descripción general, poca o ninguna preparación, poca o ninguna examinación de preparación (reunión de recorrido real) y reelaboración y seguimiento.

  • Los procesos de inspección incluyen descripción general, preparación, inspección, reelaboración y seguimiento.

  • Sin trámite formalizado en los trámites.

  • Procedimiento formalizado en cada paso.

  • Se invierte menos tiempo en el recorrido, ya que no se utiliza una lista de verificación formal para evaluar el programa.

  • La inspección lleva más tiempo ya que la lista de elementos en la lista de verificación se rastrea hasta su finalización.

  • No planificado

  • Reunión planificada con los roles fijos asignados a todos los miembros involucrados.

  • El autor lee el código del producto y su compañero de equipo presenta los defectos o sugerencias.

  • El lector lee el código del producto. Todos lo inspeccionan y detectan.

  • El autor toma nota de los defectos y sugerencias ofrecidos por su compañero de equipo.

  • Registrador registra los defectos.

  • Informal, por lo que no hay moderador.

  • El moderador tiene el papel de moderador asegurándose de que las discusiones avancen en las líneas productivas.

Itinerario

diagramaPruebasPruebasSoftware
  • Pruebas del Software

  • JUnit

  • Validar, Verificar, Probar vs Demostrar y Depurar

  • Caracrerística, SUT, DOC, Caso de Prueba

  • Ejecución de Prueba, Verde/Exito/Negativo, Falso Negativo, Rojo/Fallo/Positivo, Falso Positivo

  • Coste de Conformidad vs de No Conformidad

  • Cobertura de Pruebas

  • Pruebas de Aceptación, de Sistema, de Integración , de Componentes y Unitarias

  • Pruebas de Rendimiento, de Escalabilidad , de Usabilidad , de Seguridad, …​

  • Pruebas Estáticas vs Dinámicas

  • SonarQube, Understand, TestComplete, …​ JUnit, mockito

  • TDD, BDD, TFD y TLD

  • Integración Continua, Pruebas de Regresión y de Humo

  • Metaclases y Anotaciones

  • Framework

  • @Test, timeout, @Before, @After, @Beforeclass, @AfterClass, @RunWith, @SuiteClasses

  • assertThat, assertEquals, assertNull, assertTrue, fail, …​

  • Arrange/Setup/Given, Act/When, Assert/Then, TearDown

  • @IncludeCategory, @ExcludeCategory, @Category, @Ignored, @Parameters y @Parameter

  • Pruebas de Componentes, Integración y Sistemas, sobre-diseño

  • Pruebas Unitarias

  • Diseño de Casos de Pruebas Unitarias

  • Dobles en Pruebas Unitarias

  • Riesgos, Inocuas, Red de Seguridad

  • Automatizadas, Auto-verificables, Repetibles, Independientes, Rápidas

  • Mantenimiento, Profesionales, Fáciles de Leer/Escribir, Cohesivas, Sencillas, Expresivas

  • Legibilidad, Documentación, Calidad, Repelentes de Errores, Localizan Defectos y Especificación

  • Estrategias de Caja Negra/Comportamiento vs Caja Blanca/Estructural

  • Variables independientes, Variables dependientes, Clases de Equivalencia, Factor, Análisis de Valores Límite

  • Vectores de Pares vs Vector Ortogonal

  • Grafo de Control de Flujo de Ejecución y Complejidad Ciclomática

  • Dobles en el proceso de desarrollo: TLD, TFD, TDD

  • Escuelas de Chicago vs Londres

  • Dobles, Dummy, Fake, Stub, Mock y Spy

  • Mockito

  • @InjectMocks, @Mock, @Spy

  • matchers, Hamfcrest, ArgumentMatcher, ArgumentCaptor, InOrder

  • when, thenReturn, doReturn, doNothing, doAnswer, thenAnswer, doThrow, thenThrow, verify, times, atLeastOnce, verifyZeroInteractions

Ejemplos: TicTacToe, Mastermind, …​

Sintesis

sintesis

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada
  • xUnit Test Patterns: Refactoring Test Code

    • Gerard Meszaros

    • Addison-Wesley Educational Publishers Inc; Edición: 01 (21 de mayo de 2007)

xUnitTestPatternsRefactoringTestCode

  • Effective Unit Testing

    • Lasse Koskela

    • Manning Publications Company; Edición: 1 (16 de febrero de 2013)

EffectiveUnitTesting

  • The Art of Software Testing

    • Glenford J. Myers

    • John Wiley & Sons Inc; Edición: 3. Auflage (16 de diciembre de 2011)

TheArtofSoftwareTesting

  • Pragmatic Unit Testing in Java with JUnit

    • Andy Hunt, Dave Thomas

    • The Pragmatic Programmers (1674)

PragmaticUnitTestinginJavawithJUnit
  • Testing Computer Software

    • Cem Kaner,Jack Falk,Hung Q. Nguyen

    • Wiley John + Sons; Edición: 2nd (12 de abril de 1999)

TestingComputerSoftware

  • Diseno Agil con TDD

    • Ble Jurado, Carlos

    • Lulu.com (18 de enero de 2010)

DisenoAgilconTDD

  • Test Driven Development

    • Kent Beck

    • Addison Wesley; Edición: 01 (8 de noviembre de 2002)

TestDrivenDevelopment

  • Growing Object-Oriented Software, Guided by Tests

    • Steve Freeman

    • Addison-Wesley Professional (12 de octubre de 2009)

GrowingObjectOrientedSoftware,GuidedbyTests

  • How Google Tests Software

    • James A. Whittaker,Jason Arbon,Jeff Carollo

    • Addison-Wesley Educational Publishers Inc; Edición: 01 (2 de abril de 2012)

HowGoogleTestsSoftware

  • Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps

    • Mike Clark

    • The Pragmatic Programmers (1900)

PragmaticProjectAutomation

Ponente

  • Luis Fernández Muñoz

setillo
  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM