andreas spillner testen...unit-tests und mit ihnen getestete units werden stets parallel entwickelt....
Post on 15-Jul-2020
4 Views
Preview:
TRANSCRIPT
TESTEN WAS WAR – WAS IST – WAS WIRD!
ANDREAS SPILLNER
TESTEN WAS WAR – WAS IST – WAS WIRD!
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
2011
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1999
1990
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1984
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1984
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1977
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1973
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1965
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1958
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1949
http://www.hnf.de/dauerausstellung/highlights-des-museums.html
1946
TESTEN - WAS WAR
… UND DAS TESTEN?
▸ Wie hat es sich entwickelt?
SOFTWAREENTWICKLUNGSPROZESS NACH BENINGTON
TESTEN NACH DER CODIERUNG IN TESTSTUFEN
Benington, Herbert D.:Production of Large Computer Programs
Proc. Symp. On Advanced Computer Programs for Digital Computers" sponsored by ONR, June 1956.http://portal.acm.org/citation.cfm?id=41799
1956
SOFTWAREENTWICKLUNGSPROZESS NACH BENINGTON
TESTEN NACH DER CODIERUNG IN TESTSTUFEN
Benington, Herbert D.:Production of Large Computer Programs
Proc. Symp. On Advanced Computer Programs for Digital Computers" sponsored by ONR, June 1956.http://portal.acm.org/citation.cfm?id=41799
1956
SOFTWAREENTWICKLUNGSPROZESS NACH ROYCE
TESTEN NACH DER CODIERUNG
Royce, W. W.: Managing the Development of Large Software Systems: Concepts and Techniques Proc. WESCON, IEEE, Los Alamitos, CA, 1970http://portal.acm.org/citation.cfm?id=41801
????
1970
V-MODELL
TESTEN NACH DER CODIERUNG IN TESTSTUFEN
Barry W. Boehm: Guidelines for Verifying and Validating Software Requirements and Design Specification.EURO IFIP 79, P.A. Samet (eds.) North-Holland, IFIP 1979, 711-7191979
EXTREME PROGRAMMING
TESTEN VOR DER CODIERUNG UND IM ZENTRUM
http://www.extremeprogramming.org/rules.html
http://www.extremeprogramming.org/map/code.html2000
EXTREME PROGRAMMING
TESTEN VOR DER CODIERUNG UND IM ZENTRUM
http://www.extremeprogramming.org/rules.html
http://www.extremeprogramming.org/map/code.html
TEST-DRIVEN DEVELOPMENT ERSETZT DIE ANFORDERUNGEN ?
2000
SCRUM
TESTEN VERSCHWINDET
https://en.wikipedia.org/wiki/Scrum_(software_development)#/media/File:Scrum_process.svg2005
SCRUM
TESTEN VERSCHWINDET
https://en.wikipedia.org/wiki/Scrum_(software_development)#/media/File:Scrum_process.svg
???
ALS SICHTBARE AKTIVITÄT
2005
SCRUM
TESTEN NACH ODER IN DEN SPRINTS
▸ Extra Test-Sprint
▸ Testen als mehrfache Aktivität im Sprint
▸ Testen parallel während des Sprints
2010
TESTEN WAS WAR – WAS IST – WAS WIRD!
TESTEN - WAS IST
UMFRAGE 2016
TESTEN - WAS IST
UMFRAGE 2016
Eine Kooperation der Hochschulen Bremerhaven und Bremen,
der Technischen Hochschule Köln, des German Testing Board
und des Swiss Testing Board
Swiss Testing Board
STB
Softwaretest İn Praxis und Forschung
Umfrage 2016http://softwaretest-umfrage.de/
UMFRAGE 2016
AGILES VORGEHEN HAT AUFGESCHLOSSEN
UMFRAGE 2016
Manager optimistischer nur
4% ohne Vorgehensmodell Tester/Entwickler
liegen bei 12%
AGILES VORGEHEN HAT AUFGESCHLOSSEN
UMFRAGE 2016
AGILE PRAKTIKEN
UMFRAGE 2016
AGILE PRAKTIKEN
Seit 2011 um 15-25%
gestiegen
UMFRAGE 2016
AGILE PRAKTIKEN Nutzung der Praktiken nahezu unabhängig vom Vorgehensmodell
Seit 2011 um 15-25%
gestiegen
TESTEN - WAS IST
MEINE SUBJEKTIVE SICHT AUF
▸ Entwicklertest
▸ Test-Driven Development
▸ Continuous Integration / Integrationstest
▸ Design by Contract
TESTEN - WAS IST
ENTWICKLER TESTEN
▸ … schon immer
▸ Jeder Entwickler wird seine Software testen/ausprobieren, bevor er sie weiter- bzw. frei gibt
ENTWICKLER TESTEN
PROGRAMMIERUNG UND TEST ENGER ZUSAMMEN
Programmierung Test
� �
ENTWICKLER TESTEN
PROGRAMMIERUNG UND TEST ENGER ZUSAMMEN
Programmierung Test
� �
ENTWICKLER TESTEN
PROGRAMMIERUNG UND TEST ENGER ZUSAMMEN
ProgrammierungTest
���
ENTWICKLER TESTEN
PROGRAMMIERUNG UND TEST ENGER ZUSAMMEN
ProgrammierungTest
TESTEN UNGELIEBTE TÄTIGKEITBEI DEN ENTWICKLERN���
ENTWICKLER TESTEN
SICHT DER ENTWICKLER AUF DAS TESTEN
▸ »Using a testing technique, you would seek to exhaustively analyze the specification in question (and possibly the code) and devise tests that exhaustively cover the behavior.«
▸ Testen bringt Nichts
▸ Fehlerfreiheit kann ja nicht nachgewiesen werden
▸ Deshalb bleibt es oft beim »Ausprobieren«
Jeff Langr: Modern C++ Programming with Test-Driven Development. O’Reilly 2013
�
ENTWICKLER TESTEN
EXHAUSTIVELY? NICHT ERFORDERLICH, WEIL …
▸ Beispiel: Ein einfaches Programm hat drei ganzzahlige Eingabewerte. Jeder Eingabewert kann bei 16 Bit Integerzahlen 216 unterschiedliche Werte annehmen. Jede Kombination ist möglich, es ergeben sich somit 216 * 216 * 216 = 248 Kombinationen.
248 Kombinationen sind 281.474.976.710.656 Möglichkeiten!
Soll jede Kombination zur Ausführung kommen und werden 100.000 Kombinationen in jeder Sekunde ausgeführt, dann dauert es ca.
ENTWICKLER TESTEN
EXHAUSTIVELY? NICHT ERFORDERLICH, WEIL …
▸ Beispiel: Ein einfaches Programm hat drei ganzzahlige Eingabewerte. Jeder Eingabewert kann bei 16 Bit Integerzahlen 216 unterschiedliche Werte annehmen. Jede Kombination ist möglich, es ergeben sich somit 216 * 216 * 216 = 248 Kombinationen.
248 Kombinationen sind 281.474.976.710.656 Möglichkeiten!
Soll jede Kombination zur Ausführung kommen und werden 100.000 Kombinationen in jeder Sekunde ausgeführt, dann dauert es ca. 89 Jahre
ENTWICKLER TESTEN
ANGEMESSEN STATT AUFWENDIG TESTEN
▸ Kein Programm nutzt alle Möglichkeiten der Eingabe,warum dann beim Testen den Anspruch haben?
▸ Angemessen Testen:
▸ Häufige Nutzung,
▸ risikoreiche Fehler,
▸ Ausnahmefälle
▸ Testentwurfsverfahren / Teststandards helfen
ENTWICKLER TESTEN
UMFRAGE 2016
▸ Entwickler sind unsicher, ob aus- reichend genug getestet wird!
▸ Woran liegt es?
K. Vosseberg, A. Spillner, M.Winter: Umfrage 2016 - Softwaretest in Praxis und Forschung, dpunkt.Verlag, 2017
TESTEN - WAS IST
TEST-DRIVEN DEVELOPMENT
▸ Tests werden vor der Programmierung geschrieben
▸ Tests werden automatisiert durchgeführt (X-Unit-Tools)
▸ bis der Balken grün ist, also alle spezifizierten Tests ohne Fehler durchlaufen
▸ Keine Teststrategie, sondern eine Designstrategie
▸ Festlegung der Schnittstelle
https://www.it-agile.de/de/wissen/agiles-engineering/testgetriebene-entwicklung-tdd/
TEST-DRIVEN DEVELOPMENT
TEST-DRIVEN DEVELOPMENT
▸ » … Unit-Tests und mit ihnen getestete Units werden stets parallel entwickelt. Die eigentliche Programmierung erfolgt in kleinen, wiederholten Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, hat drei Hauptteile: 1. Schreibe einen Test …
2. Ändere den Programmcode …3. Räume dann im Code auf …«
https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung 8.3.2017
TEST-DRIVEN DEVELOPMENT
TEST-DRIVEN DEVELOPMENT
▸ » … Diese drei Schritte werden so lange wiederholt, bis die bekannten Fehler bereinigt sind, der Code die gewünschte Funktionalität liefert und dem Entwickler
keine sinnvollen weiteren Tests mehr einfallen, welche vielleicht noch scheitern könnten. … «
▸ Es gibt bessere und nachvollziehbare Kriterien zur Beendigung des Testens
https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung 8.3.2017
TEST-DRIVEN DEVELOPMENT
SQ-MAGAZIN 03/17
▸ »Der Vorteil von Test-Experten in TDD
… In einem agilen Projekt existiert zwar keine absolute Abgrenzung zwischen den Aufgabengebieten, trotzdem sollte die Rolle des Testers Beachtung finden. Die Erfahrung zeigt, dass eine Rolle, welche sich primär um das Erkennen von Risiken und Fehlern in der Software kümmert, auch bessere Ergebnisse liefert als eine gemischte Rolle, der diese Aufgabe nur zufällig zugeteilt wurde. … werden die Testfälle allerdings ausführlich und methodisch geschrieben, ergibt sich hierdurch ein roter Faden, … «
Sacha Rezagholinia: Hohe Qualität durch eine testgetriebene Entwicklung, Vor- und Nachteile von Test Drive Development (TDD), SQMagazin, 42, März 2017, S. 34-37
TEST-DRIVEN DEVELOPMENT
»DIE TRÜGERISCHE SICHERHEIT DES GRÜNEN BALKENS«
▸ »Test-Driven Devleopment wird derzeit zwar in mancher Hinsicht kontrovers diskutiert, dessen ungeachtet jedoch immer häufiger in der Praxis eingesetzt. Ein wichtiger Aspekt dieses Vorgehens ist der weitgehende Verzicht auf eine umfassende Dokumentation, an deren Stelle die Erstellung der Tests vor der Programmierung tritt. In dem Artikel wird an einem Beispiel demonstriert, welche Vorteile gerade hier eine systematische
Erstellung der Testfälle mit sich bringt.«
Falk Fraikin, Matthias Hamburg, Stefan Jungmayr, Thomas Leonhardt, Andreas Schönknecht, Andreas Spillner und Mario Winter : Die trügerische Sicherheit des grünen Balkens. OBJEKTspektrum, Heft 1, Januar/Februar 2004, S. 25-29.
OBJEKTSPEKTRUM 01/2004
LEAN TESTING
LEAN TESTING
▸ … unterstützt Entwickler einen angemessenen und nicht zu aufwendigen Test durchzuführen
▸ alle wichtigen Testfälle zur Prüfung der Software zu berücksichtigen
▸ nachvollziehbare Testendekriterien zu definieren
▸ aber den Testaufwand in einem überschaubaren Rahmen zu halten
▸ Angemessen statt aufwendig Testen
ACHTUNGWERBUNG
TESTEN - WAS IST
CONTINUOUS INTEGRATION
▸ Nach der Programmierung und den erfolgreich durchgeführten Unit-Test wird eingecheckt
▸ und die System-/Regressionstests werden durchlaufen
▸ Scheint derzeit den Integrationstest zu ersetzten
▸ Vorsicht!
CONTINUOUS INTEGRATION
INTEGRATIONSTEST
▸ Vom Unit-Test zum Integrationstest
CONTINUOUS INTEGRATION
INTEGRATIONSTEST
▸ Vom Unit-Test zum Integrationstest
�
CONTINUOUS INTEGRATION
INTEGRATIONSTEST
▸ Alle Möglichkeiten einer Schnittstelle
▸ Alle Aufrufstellen zwischen zwei Programmmodulen
▸ Alle Aufrufstellen zu einem Programmmodul
▸ Kontrollfluss &Datenfluss
CONTINUOUS INTEGRATION
INTEGRATIONSTEST
▸ Alle Möglichkeiten einer Schnittstelle
▸ Alle Aufrufstellen zwischen zwei Programmmodulen
▸ Alle Aufrufstellen zu einem Programmmodul
▸ Kontrollfluss &Datenfluss
��
CONTINUOUS INTEGRATION
INTEGRATIONSTEST
▸ Alle Möglichkeiten einer Schnittstelle
▸ Alle Aufrufstellen zwischen zwei Programmmodulen
▸ Alle Aufrufstellen zu einem Programmmodul
▸ Kontrollfluss &Datenfluss
CONTINUOUS INTEGRATION
INTEGRATIONSTEST
▸ Alle Möglichkeiten einer Schnittstelle
▸ Alle Aufrufstellen zwischen zwei Programmmodulen
▸ Alle Aufrufstellen zu einem Programmmodul
▸ Kontrollfluss &Datenfluss ��
CONTINUOUS INTEGRATION
INTEGRATIONSTEST
▸ Alle Möglichkeiten einer Schnittstelle
▸ Alle Aufrufstellen zwischen zwei Programmmodulen
▸ Alle Aufrufstellen zu einem Programmmodul
▸ Kontrollfluss &Datenfluss
�einchecken
✔
TESTEN - WAS IST
SCHNITTSTELLENSPEZIFIKATION
▸ TDD reicht nicht aus
▸ Integrationstest ist sehr aufwendig
▸ Was kann helfen?
▸ Design by Contract
DESIGN BY CONTRACT
DESIGN BY CONTRACT
▸ Ziel: reibungsloses Zusammenspiel einzelner Programmmodule (oder Klassen, Methoden, Funktionen)
▸ Zu jeder Schnittstelle wird ein Vertrag geschlossen, der bei der Verwendung der Schnittstelle einzuhalten ist
▸ Vorbedingungen (pre-conditions) Zusicherungen, die vom Aufrufer einzuhalten sind
▸ Nachbedingungen (post-conditions) Zusicherungen, die der Aufgerufene garantiert, und
▸ Invarianten (invariants)Bedingungen, die durch den Aufruf unverändert bleiben
DESIGN BY CONTRACT
BEISPIEL: VERWALTUNG VON MIETSHÄUSERN
▸ Vorbedingung: Eine Wohnung kann nur vermietet werden, wenn sie zum Mietshaus gehört („nr" im entsprechenden Bereich) und nicht bereits vermietet ist
▸ Nachbedingung: Die Wohnung ist dann vermietet und es gibt eine Wohnung weniger zu vermieten
▸ Invarianten: Anzahl der Wohnungen > 0 und Summe aus leeren + vermieteten Wohnungen = Anzahl der Wohnungen
•Wolffram, J.: „Desing by Contract“: Verträge schaffen Qualität. OBJEKTspektrum, Nov/Dez. 1996, Nr. 6, 63-67
DESIGN BY CONTRACT
BEISPIEL IN EIFFEL
vermiete (nr: INTEGER) is --vermiete Wohnung mit Nummer nr
require nr_zulaessig: 1 <= nr and nr <= wohnungen wohnung_leer: leer(nr)
ensure vermietet: not leer(nr) weniger_leere_Wohnungen: leere_wohnungen = old leere_wohnungen -1 end --vermiete
•Wolffram, J.: „Desing by Contract“: Verträge schaffen Qualität. OBJEKTspektrum, Nov/Dez. 1996, Nr. 6, 63-67
DESIGN BY CONTRACT
VORTEILE
▸ Durch die im Vertrag festgelegten Zuständigkeiten lässt sich der Testaufwand unter Verwendung von Testverfahren angemessen gestalten.
▸ Beispielsweise schränkt die Vorbedingung nr_zulaessig: 1 <= nr and nr <= wohnungen den zulässigen Datenbereich ein
▸ Tests mit negativen Zahlen, Sonderzeichen usw. können entfallen
▸ Der Aufrufer muss sicherstellen, dass nur zulässige Werte übergeben werden
DESIGN BY CONTRACT
POSITIVE AUSWIRKUNGEN
▸ auf den Unit-
▸ und den Integrationstest
▸ Sicherstellung, dass Vor-& Nachbedingung eingehaltenwerden und Invariantenunverändert bleiben
TESTEN - WAS IST
EMPFEHLUNG
▸ Entwicklertest - jaABER Testwissen ist hilfreich
▸ TDD - ja ABER Testfälle systematisch herleiten
▸ Continuous Integration - jaABER Integrationstest nicht vernachlässigen
▸ TDD als Schnittstellenspezifikation - jaABER durch Design by Contract ergänzen
✔
✔
✔
✔
TESTEN - WAS IST
EMPFEHLUNG
▸ Entwicklertest - jaABER Testwissen ist hilfreich
▸ TDD - ja ABER Testfälle systematisch herleiten
▸ Continuous Integration - jaABER Integrationstest nicht vernachlässigen
▸ TDD als Schnittstellenspezifikation - jaABER durch Design by Contract ergänzen
✔
✔
✔
✔
»ES« IST ALLES DA! »ES« MUSS NUR
GENUTZT WERDEN!
TESTEN - WAS IST
EMPFEHLUNG
▸ Entwicklertest - jaABER Testwissen ist hilfreich
▸ TDD - ja ABER Testfälle systematisch herleiten
▸ Continuous Integration - jaABER Integrationstest nicht vernachlässigen
▸ TDD als Schnittstellenspezifikation - jaABER durch Design by Contract ergänzen
✔
✔
✔
✔
»ES« IST ALLES DA! »ES« MUSS NUR
GENUTZT WERDEN!
PROBIEREN SIE »ES« DOCH MAL AUS!
TESTEN WAS WAR – WAS IST – WAS WIRD!
TESTEN - WAS WIRD
BLICK IN DIE ZUKUNFT
TESTEN - WAS WIRD
2005 UM PROGNOSEN GEBETEN
▸ Einige der Prognosen von vor 12 Jahren
PROGNOSEN AUS DEM JAHR 2005
HANS SCHÄFER, SOFTWARE TEST CONSULTING, NORWEGEN
▸ »Testen verschwindet nicht. Im Gegenteil, es wird mehr
werden. Die Ursache ist mehr Komplexität und mehr Globalisierung, Outsourcing etc. Der Fokus des Testens wird mehr und mehr die Beschaffung von Information über das zu testende Objekt.
▸ Ich denke auch, dass es mehr normal wird, das Prüfen und Testen wie bei anderen Ingenieurdisziplinen zu betreiben. Das bedeutet vor allem, dass man früher daran denkt, es
mehr systematisch betreibt und mit Ressourcen ausstattet.«
PROGNOSEN AUS DEM JAHR 2005
PROGNOSEN FÜR 2010
PROGNOSEN AUS DEM JAHR 2005
PROGNOSEN FÜR 2010
EINGETRETEN?
PROGNOSEN AUS DEM JAHR 2005
HANS SCHÄFER, SOFTWARE TEST CONSULTING, NORWEGEN
▸ »Es wird sich durchsetzen, dass auf jeden Fall ein gewisser
Komponententest durchgeführt werden sollte und mitgeliefert
wird. Werkzeuge wie Junit werden mehr und mehr zum Standard bei der Entwicklung von Komponenten.
▸ Auf der anderen Seite sehe ich keine Tendenz dazu, dass dieser Test auch den notwendigen Umfang erreicht, die notwendige Gründlichkeit, denn die tonangebenden Mitarbeiter werden auch weiterhin nur sehr wenig im Testen ausgebildet. Ich denke, dass trotz der Initiativen wie ISTQB und dem Buch "Basiswissen Softwaretest" das Fachgebiet weiterhin ein Stiefkind sein wird.«
PROGNOSEN AUS DEM JAHR 2005
KAROL FRÜHAUF, INFOGEM, SCHWEIZ
▸ »Ich befürchte, es wird so aussehen wie heute.
▸ Ich hoffe, dass automatischer Unit Test für die Absolventen irgendeiner Informatik-Ausbildung so selbstverständlich
ist wie das Zähneputzen. Reviews in irgendeiner Form auch.«
PROGNOSEN AUS DEM JAHR 2005
INA SCHIEFERDECKER, FRAUNHOFER FOKUS
▸ »Noch immer werden alle sagen, wie wichtig Testen ist, aber nicht die notwendigen Ressourcen (Zeit, Werkzeuge,
Personal) zur Verfügung stellen und sich mit im Wesent-lichen mit Unit-Level Tests beruhigen und begnügen.
▸ Es wird aber ein Umdenken stattfinden, da einige größere Systemausfälle wegen fehlerhafter Software zu verzeich-nen sein werden - auch in der Ausbildung rückt das Thema immer mehr in den Blickwinkel.«
PROGNOSEN AUS DEM JAHR 2005
ANDREAS SPILLNER, HOCHSCHULE BREMEN
▸ »Softwareentwicklung erfolgt in Komponenten,
Produktlinien (konstruktive Wiederverwendung!).Zu jeder Komponenten werden die Testfälle mitgeliefert
▸ als Nachweis des sorgsam durchgeführten Tests und
▸ als zusätzliche Spezifikation!
▸ Es ist kein Grund erkennbar, warum die Testfälle nicht mitgeliefert werden sollten, es sei denn, es wurde nicht ausreichend getestet!«
PROGNOSEN AUS DEM JAHR 2005
PROGNOSEN FÜR 2020
PROGNOSEN AUS DEM JAHR 2005
PROGNOSEN FÜR 2020
IN 3 JAHREN!
PROGNOSEN AUS DEM JAHR 2005
KAROL FRÜHAUF, INFOGEM, SCHWEIZ
▸ »Ich befürchte, nicht viel anders als heute.
▸ Ich hoffe, dass Software-Entwicklung kein single, kein pair
sondern team programming ist. Das Team sitzt in einem (virtuellen) Raum und erarbeitet die Lösung in dem alle Aspekte ausdiskutiert werden, laufend mit einer cleveren
Notation auf einer hohen Abstraktionsebene für alle
sichtbar fest gehalten werden und unmittelbar auf eine ganze Menge syntaktischer und einige semantische
Mängel hin automatisch geprüft werden.«
PROGNOSEN AUS DEM JAHR 2005
INA SCHIEFERDECKER, FRAUNHOFER FOKUS
▸ »Parallel dazu haben wir Tester aber die Technologie
vorangebracht und können sie dann bei Bedarf aus der Tasche ziehen und anwenden.
▸ Sowieso wird nun im Wesentlichen modell-basiert
entwickelt - und getestet - in einem durchgängigen
Prozess: es gibt dabei aber vielfältige Prozesse, die auf
den Bedarf der Technologien, Systeme, etc. angewendet
werden.«
PROGNOSEN AUS DEM JAHR 2005
EIKE RIEDEMANN, UNIVERSITÄT DORTMUND
▸ »Die EU hat eine Software-Test-Richtlinie erlassen. Danach muss für ausgelieferte Software offengelegt werden,
welche Tests mit welcher Qualität (z.B. Überdeckungsrate) absolviert wurden.
▸ Einige Firmen haben den Model Maturity Level 5 ("models only") erreicht, d.h. der Code wird automatisch aus den
präzisen Modellen erzeugt, die z.B. mit UML 9.0 beschrie-ben sind. Tester müssen also nur noch die Modelle
gegenüber den Kundenanforderungen validieren.«
PROGNOSEN AUS DEM JAHR 2005
ANDREAS SPILLNER, HOCHSCHULE BREMEN
▸ »Einbau von Plausibilität (nicht nur bei Übergabe von Parametern) sondern auch in den „Berechnungen",
▸ was wir Menschen auch machen (Bei Ergebnissen fragen wir: „Kann das stimmen?“
▸ Leider zu nehmend aus der Mode gekommen bzw. es kann kaum noch einer! Überschlagsrechnung!)«
PROGNOSEN AUS DEM JAHR 2005
MARTIN GLINZ, UNIVERSITÄT ZÜRICH
▸ »Gesellschaftlich: In der Rubrik "Vermischtes" der Zeitungen werden neben den Verkehrstoten auch die Softwaretoten gemeldet. Nur in besonders krassen Fällen gibt es öffentlichen Aufschrei und Bestrafung der Schuldigen (genau wie heute im Straßenverkehr).«
PROGNOSE AUS DEM JAHR 1954
PROGNOSE FÜR 2004
PROGNOSE AUS DEM JAHR 1954
PROGNOSE FÜR 2004
AUS DEM JAHR 1954
PROGNOSEN AUS DEM JAHR 1954
PROGNOSEN SIND SCHWIERIG
▸ Home-Computer-Vision(kommt aus dem Internet - also ohne Gewähr!)
https://www.computerbase.de/2004-12/computervision-des-jahres-1954-fuer-2004/
DANKE FÜR IHRE AUFMERKSAMKEIT
FRAGEN
▸ jetzt oder auch später
▸ andreas.spillner@hs-bremen.de
top related