Testen weiße Kiste

Usability-Tests

A) Belastungstest

Leistungstest

Funktionsprüfung

Testen Software

Testen ist der Prozess der Ausführung eines Programms (oder Teils eines Programms) mit der Absicht (oder dem Zweck), Fehler zu finden.

Es gibt mehrere Kriterien, nach denen es üblich ist, Arten von Tests zu klassifizieren. Normalerweise werden die folgenden Zeichen unterschieden:

I) Je nach Prüfgegenstand:

(Ermittlung oder Erhebung von Leistungsindikatoren und Reaktionszeit eines Software- und Hardwaresystems oder -geräts als Antwort auf eine externe Anfrage, um die Einhaltung der Anforderungen an dieses System festzustellen)

b) Belastungstests

(bewertet die Zuverlässigkeit und Stabilität des Systems bei Überschreitung der Grenzen des Normalbetriebs.)

c) Stabilitätsprüfung

4) Testen der Benutzeroberfläche

5) Sicherheitstests

6) Lokalisierungstests

7) Kompatibilitätstest

II) Durch Kenntnis des Systems:

1) Black-Box-Tests

(es wird ein Objekt getestet, dessen interne Struktur unbekannt ist)

(die interne Struktur des Programms wird überprüft, Testdaten werden durch Analyse der Programmlogik gewonnen)

III) Nach Automatisierungsgrad:

1) Manuelle Prüfung

2) Automatisiertes Testen

3) Halbautomatisches Testen

IV) Je nach Isolationsgrad der Komponenten:

1) Testen von Komponenten (Einheiten).

2) Integrationstest

3) Systemtest

V) Zum Zeitpunkt der Prüfung:

1) Alpha-Test- ein geschlossener Prozess zum Testen des Programms durch Vollzeit-Entwickler oder -Tester. Ein Alpha-Produkt ist meist nur zu 50% fertig, es gibt einen Programmcode, aber ein wesentlicher Teil des Designs fehlt.

2) Beta-Test- häufige Verwendung fertige Fassung Programme, um die maximale Anzahl von Fehlern in seiner Arbeit für deren anschließende Beseitigung vor dem endgültigen Markteintritt an den Massenverbraucher zu identifizieren. An den Tests sind Freiwillige aus dem Kreis der gewöhnlichen zukünftigen Benutzer beteiligt.

Softwareverifizierung ist ein allgemeineres Konzept als Testen. Der Zweck der Verifikation besteht darin, Gewissheit zu erlangen, dass das zu verifizierende Objekt (Anforderungen oder Programmcode) die Anforderungen erfüllt, ohne unbeabsichtigte Funktionen implementiert ist und die Designspezifikationen und -standards erfüllt ( ISO 9000-2000). Der Verifizierungsprozess umfasst Inspektionen, Codetests, Analyse der Testergebnisse, Generierung und Analyse von Problemberichten. Somit ist es allgemein akzeptiert, dass der Testprozess ist BestandteilÜberprüfungsprozess.

Sankt Petersburg

Staatliche Elektrotechnische Hochschule

Abteilung MOEM

nach Disziplin

„Softwareentwicklungsprozess“

„Software-Verifizierung“

St. Petersburg

Zweck der Überprüfung ………………………………………………………………… Seite 3

Vorbemerkungen………………………………………………………………….. Seite 3

Spezielle und allgemeine Ziele …………………………………………….. Seite 4

Erwartete Praxis durch Ziele ……………………………………… Seite 4

SG1 Vorbereitung zur Verifizierung……………………………………………………………………………………………………………………………………………………………………………………………………………………

SG2 Durchführung von Prüfungen (Peer Assessment) ………………………… Seite 7

SG3 Umsetzung der Verifizierung ……………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………… dar

Anhang 1. Übersicht der Automatisierungstools für den Verifizierungsprozess……….. Seite 11

Anhang 2. Haupt moderne Ansätze zur Überprüfung…………….. Seite 12

Liste der verwendeten Literatur ………………………………………………….. Seite 14

Ein integriertes Modell für Exzellenz und Reife

Verifizierung (Reifegrad 3)

Ziel

Der Zweck der Überprüfung ist Gewährleistung, dass die ausgewählte Middleware oder das Endprodukt die festgelegten Anforderungen erfüllt.

1. Wassernoten

Verifizierung von Softwareprodukten ist Überprüfung des Endprodukts oder seiner Zwischenversionen um die ursprünglichen Anforderungen zu erfüllen. Dies beinhaltet nicht nur das Testen des Programms selbst, sondern auch das Auditieren des Projekts, der Benutzer- und technischen Dokumentation usw.

Der Zweck der Verifizierung von Softwaresystemen besteht darin, Fehler zu identifizieren und zu melden, die während der Lebenszyklusphasen auftreten können. Hauptaufgaben der Verifizierung:

Bestimmen der Übereinstimmung von High-Level-Anforderungen mit Systemanforderungen;

Berücksichtigung von High-Level-Anforderungen in der Systemarchitektur;

Einhaltung der Architektur und Anforderungen dafür im Quellcode;

Bestimmen der Übereinstimmung des ausführbaren Codes mit den Anforderungen für das System;

Ermittlung der Mittel zur Lösung der oben genannten Aufgaben, die technisch richtig und ausreichend vollständig sind.

Die Verifizierung umfasst die Verifizierung von Endprodukten und Verifizierung von Zwischenprodukten anhand aller ausgewählten Anforderungen, einschließlich Kundenanforderungen, Anforderungen an Endprodukte und Anforderungen an seine einzelnen Komponenten.

Die Verifizierung ist von Natur aus ein inkrementeller (inkrementeller) Prozess vom Moment ihres Beginns über die Entwicklung von Produkten und alle Arbeiten an Produkten. Die Verifizierung beginnt mit der Verifizierung der Anforderungen, folgt dann der Verifizierung aller Zwischenprodukte in verschiedenen Phasen ihrer Entwicklung und Herstellung und endet mit der Verifizierung des Endprodukts.

Die Verifizierung von Zwischenprodukten in jeder Phase ihrer Entwicklung und Herstellung erhöht die Wahrscheinlichkeit, dass das Endprodukt die Anforderungen des Kunden, die Anforderungen an das Endprodukt und die Anforderungen an seine einzelnen Komponenten erfüllt, erheblich.

Verifikation und Validierung von Prozessen sind im Wesentlichen verwandte Prozesse, die jedoch darauf abzielen, unterschiedliche Ergebnisse zu erzielen. Der Zweck der Validierung besteht darin, nachzuweisen, dass das fertige Produkt tatsächlich seinen ursprünglichen Zweck erfüllt. Die Verifizierung soll sicherstellen, dass das Produkt bestimmte Anforderungen genau erfüllt. Mit anderen Worten, die Verifizierung stellt sicher, dass „ du machst es richtig“, und Validierung ist, dass „ Sie tun das Richtige”.

Die Verifizierung sollte so früh wie möglich in relevante Prozesse (wie Lieferung, Entwicklung, Betrieb oder Wartung) implementiert werden, um die Wirtschaftlichkeit und Leistung zu bewerten. Dieser Prozess kann Analyse, Verifizierung und Prüfung (Prüfung) umfassen.

Dieser Prozess kann mit unterschiedlichem Grad an Unabhängigkeit der Ausführenden durchgeführt werden. Der Grad der Unabhängigkeit der ausübenden Künstler kann sowohl zwischen verschiedenen Einheiten in der Organisation selbst als auch zwischen Einheiten in einer anderen Organisation verteilt sein, mit unterschiedlichem Grad an Verantwortungsverteilung. Dieser Vorgang wird Prozess genannt unabhängige Überprüfung wenn die durchführende Organisation vom Hersteller, Entwickler, Betreiber oder Betreuer unabhängig ist.

Gutachten (Sachverstand) sind ein wichtiger Bestandteil der Verifikation als etabliertes Werkzeug zur effektiven Fehlerbeseitigung. Eine wichtige Erkenntnis daraus ist die Notwendigkeit, ein tieferes Verständnis und Verständnis für die Arbeitsversionen des Produkts sowie für die Arbeitsabläufe zu entwickeln, die verwendet werden, um mögliche Fehler zu identifizieren und gegebenenfalls Gelegenheiten für Verbesserungen zu schaffen.

Die Prüfungen umfassen eine methodische Untersuchung der von Experten durchgeführten Arbeiten, um Mängel und andere erforderliche Änderungen zu identifizieren.

Die wichtigsten Methoden der Expertenbewertung sind:

Inspektion

End-to-End-Strukturkontrolle

Die beiden Konzepte Validierung und Verifikation werden oft verwechselt. Darüber hinaus wird die Systemanforderungsvalidierung oft mit der Systemvalidierung verwechselt. Ich schlage vor, sich mit diesem Problem zu befassen.

In dem Artikel habe ich zwei Ansätze zur Objektmodellierung betrachtet: als Ganzes und als Struktur. Im aktuellen Artikel werden wir diese Aufteilung benötigen.

Angenommen, wir haben ein entworfenes funktionales Objekt. Lassen Sie uns dieses Objekt als Teil der Konstruktion eines anderen funktionalen Objekts betrachten. Lassen Sie es eine Beschreibung der Konstruktion des Objekts geben, so dass es eine Beschreibung des Objekts enthält. In einer solchen Beschreibung wird das Objekt als Ganzes beschrieben, dh seine Interaktionsschnittstellen mit anderen Objekten werden im Rahmen der Konstruktion des Objekts beschrieben. Gegeben sei die Beschreibung des Objekts als Struktur. Gegeben sei ein Informationsobjekt, das Anforderungen an die Gestaltung der Beschreibung des Objekts als Struktur enthält. Es gebe ein Wissen, das Inferenzregeln enthält, auf deren Grundlage aus der Beschreibung des Objekts als Ganzes eine Beschreibung des Objekts als Struktur gewonnen wird. Der Wissensschatz ist das, was Designern in Instituten beigebracht wird – viel, viel Wissen. Sie erlauben es, auf der Grundlage des Wissens über das Objekt, dessen Struktur zu entwerfen.

Sie können also beginnen. Wir können behaupten, dass, wenn das Objekt als Ganzes korrekt beschrieben ist, wenn der Wissensbestand korrekt ist und wenn die Schlußregeln eingehalten wurden, die resultierende Beschreibung der Konstruktion des Objekts korrekt sein wird. Das heißt, auf der Grundlage dieser Beschreibung, ein funktionelles Objekt entsprechend reale Bedingungen Betrieb. Welche Risiken können auftreten:

1. Verwendung von falschem Wissen über das Objekt. Das Modell des Objekts in den Köpfen der Menschen entspricht möglicherweise nicht der Realität. Sie kannten zum Beispiel die wirkliche Gefahr von Erdbeben nicht. Dementsprechend können die Anforderungen an das Objekt falsch formuliert sein.

2. Unvollständige Aufzeichnung des Wissens über das Objekt - etwas wird übersehen, Fehler werden gemacht. Sie wussten zum Beispiel von den Winden, vergaßen es aber zu erwähnen. Dies kann zu einer unzureichend vollständigen Beschreibung der Anforderungen an das Objekt führen.

3. Falsches Wissen. Uns wurde beigebracht, dass die Masse Vorrang vor anderen Parametern hat, aber es stellte sich heraus, dass wir die Geschwindigkeit erhöhen mussten.

4. Falsche Anwendung von Inferenzregeln auf die Objektbeschreibung. Logische Fehler, etwas fehlt in den Anforderungen für das Objektdesign, die Anforderungsverfolgung ist unterbrochen.

5. Unvollständige Aufzeichnung der erhaltenen Schlussfolgerungen über die Auslegung des Systems. Alles wurde berücksichtigt, alles wurde berechnet, aber sie haben vergessen zu schreiben.

6. Das erstellte System entspricht nicht der Beschreibung.

Es ist klar, dass alle Projektartefakte in der Regel erst am Ende des Projekts in ihrer fertigen Form erscheinen, und selbst dann nicht immer. Aber wenn wir davon ausgehen, dass die Entwicklung ein Wasserfall ist, dann sind die Risiken so, wie ich sie beschrieben habe. Die Überprüfung jedes Risikos ist eine spezifische Operation, der ein Name gegeben werden kann. Wenn jemand interessiert ist, können Sie versuchen, diese Begriffe zu erfinden und auszusprechen.

Was ist Verifizierung? Verifizierung ist im Russischen eine Überprüfung der Einhaltung der Regeln. Die Regeln liegen in Form eines Dokuments vor. Das heißt, es sollte ein Dokument mit Dokumentationsanforderungen geben. Wenn die Dokumentation die Anforderungen dieses Dokuments erfüllt, hat sie die Verifizierung bestanden.

Was ist Validierung? Validierung ist im Russischen die Überprüfung der Richtigkeit der Schlussfolgerungen. Das heißt, es sollte einen Wissensbestand geben, der beschreibt, wie man eine Beschreibung eines Designs basierend auf Objektdaten erhält. Die Überprüfung der Richtigkeit der Anwendung dieser Schlussfolgerungen ist eine Validierung. Validierung ist unter anderem die Überprüfung der Beschreibung auf Konsistenz, Vollständigkeit und Verständlichkeit.

Die Anforderungsvalidierung wird oft mit der Validierung eines Produkts verwechselt, das auf diesen Anforderungen aufbaut. Es lohnt sich nicht, das zu tun.

das Team mehr als zwei Personen umfasst, stellt sich zwangsläufig die Frage nach der Verteilung von Rollen, Rechten und Verantwortlichkeiten im Team. Ein bestimmter Satz von Rollen wird durch viele Faktoren bestimmt - die Anzahl der Entwicklungsteilnehmer und ihre persönlichen Präferenzen, die angewandte Entwicklungsmethodik, Projektmerkmale und andere Faktoren. In fast jedem Entwicklungsteam können die folgenden Rollen unterschieden werden. Einige von ihnen können vollständig fehlen, während einzelne Personen mehrere Rollen gleichzeitig übernehmen können, aber die Gesamtzusammensetzung ändert sich kaum.

Kunde (Antragsteller). Diese Rolle gehört einem Vertreter der Organisation, die das zu entwickelnde System in Auftrag gegeben hat. Typischerweise ist der Antragsteller in seiner Interaktion eingeschränkt und kommuniziert nur mit Projektmanagern und einem Zertifizierungs- oder Implementierungsspezialisten. Normalerweise hat der Kunde das Recht, die Anforderungen an das Produkt zu ändern (nur in Zusammenarbeit mit Managern), die Design- und Zertifizierungsdokumentation zu lesen, die sich auf die nicht-technischen Merkmale des zu entwickelnden Systems auswirkt.

Projektmanager. Diese Rolle stellt einen Kommunikationskanal zwischen dem Kunden und dem Projektteam bereit. Der Produktmanager verwaltet die Erwartungen des Kunden und entwickelt und pflegt den Geschäftskontext für das Projekt. Seine Arbeit hat nicht direkt mit dem Verkauf zu tun, er konzentriert sich auf das Produkt, seine Aufgabe ist es, zu definieren und bereitzustellen Kundenanforderungen. Der Projektleiter hat das Recht, die Anforderungen an das Produkt und die Enddokumentation für das Produkt zu ändern.

Progamm Manager. Diese Rolle verwaltet die Kommunikation und Beziehungen innerhalb des Projektteams, fungiert in gewisser Weise als Koordinator, entwickelt und verwaltet funktionale Spezifikationen, pflegt den Projektplan und berichtet über den Projektstatus und initiiert kritische Entscheidungen für das Projekt.

Testen- der Prozess der Ausführung eines Programms, um einen Fehler zu erkennen.

Testdaten- Eingänge, die zum Testen des Systems verwendet werden.

Testsituation (Testfall)- Eingaben zum Testen des Systems und erwartete Ausgaben in Abhängigkeit von den Eingaben, wenn das System gemäß der Anforderungsspezifikation funktioniert.

Guter Testfall- eine Situation, die mit hoher Wahrscheinlichkeit einen noch nicht erkannten Fehler entdeckt.

Glücksprobe- ein Test, der einen noch nicht erkannten Fehler erkennt.

Fehler- die Handlung eines Programmierers in der Entwicklungsphase, die dazu führt, dass die Software einen internen Fehler enthält, der beim Betrieb des Programms zu einem falschen Ergebnis führen kann.

Ablehnung- unvorhersehbares Verhalten des Systems, das zu einem unerwarteten Ergebnis führt, das durch die darin enthaltenen Fehler verursacht werden könnte.

Daher wird im Prozess des Softwaretestens in der Regel Folgendes überprüft.

Verifizierung und Validierung ( Verifizierung und Validierung-V& v) dienen dazu, die korrekte Ausführung und Übereinstimmung der Software mit den Spezifikationen und Anforderungen des Kunden zu analysieren, zu verifizieren. Diese Methoden zur Überprüfung der Korrektheit von Programmen bzw. Systemen bedeuten:

• Verifizierung ist die Verifizierung der Korrektheit der Erstellung des Systems gemäß seiner Spezifikation;
• Die Validierung ist eine Überprüfung der Richtigkeit der Erfüllung der spezifizierten Anforderungen an das System.

Die Verifizierung hilft, nach Abschluss des Entwurfs und der Entwicklung eine Schlussfolgerung über die Korrektheit des erstellten Systems zu ziehen. Die Validierung ermöglicht es Ihnen, die Machbarkeit bestimmter Anforderungen festzustellen und umfasst eine Reihe von Maßnahmen, um die richtigen Programme und Systeme zu erhalten, nämlich:

• Planung von Inspektions- und Kontrollverfahren Designentscheidungen und Anforderungen;
• Bereitstellung des Automatisierungsgrades des Programmdesigns durch CASE-Mittel;
• Überprüfung des korrekten Funktionierens von Programmen durch Testmethoden an einer Reihe von Zieltests;
• Anpassung des Produkts an die Betriebsumgebung usw.

Die Validierung führt diese Aktivitäten aus, indem sie die Spezifikationen und Design-Outputs in den Lebenszyklusphasen überprüft und inspiziert, um zu bestätigen, dass die anfänglichen Anforderungen korrekt implementiert sind und dass die festgelegten Bedingungen und Einschränkungen erfüllt sind. Zu den Aufgaben der Verifikation und Validierung gehört die Überprüfung der Vollständigkeit, Konsistenz und Eindeutigkeit der Anforderungsspezifikation und der Korrektheit der Ausführung der Systemfunktionen.

Verifizierung und Validierung unterliegen:

• die Hauptkomponenten des Systems;
• Schnittstellen von Komponenten (Software, technische und informationelle) und Interaktionen von Objekten (Protokolle und Nachrichten), die die Implementierung des Systems in verteilten Umgebungen gewährleisten;
• Zugriffsmöglichkeiten auf die Datenbank und Dateien (Transaktionen und Nachrichten) und Überprüfung der Schutzmaßnahmen gegen unbefugten Zugriff auf Daten verschiedener Benutzer;
• Dokumentation für die Software und für das System als Ganzes;
• Tests, Testverfahren und Eingabedaten.

Mit anderen Worten, die wichtigsten systematischen Methoden der Programmkorrektheit sind:

• Überprüfung Validierung von PS-Komponenten und Anforderungsspezifikationen;
• PS-Inspektion Konformität des Programms mit vorgegebenen Spezifikationen festzustellen;
• testen Ausgabecode des PS auf Testdaten in einer bestimmten Betriebsumgebung, um Fehler und Defekte zu identifizieren, die durch verschiedene Fehler, Anomalien, Geräteausfälle oder Systemabstürze verursacht werden (siehe Kapitel 9).

ISO/IEC 3918-99 und 12207 beinhalten Verifizierungs- und Validierungsprozesse. Für sie werden Ziele, Aufgaben und Maßnahmen definiert, um die Richtigkeit des erstellten Produkts (einschließlich Arbeits- und Zwischenprodukte) in den Phasen des Lebenszyklus und die Einhaltung seiner Anforderungen zu überprüfen.

Die Hauptaufgabe der Verifizierungs- und Validierungsprozesse besteht darin überprüfen und bestätigen dass die endgültige Software für den Zweck geeignet ist und die Anforderungen des Kunden erfüllt. Diese Prozesse ermöglichen es Ihnen, Fehler in den Arbeitsergebnissen der Phasen des Lebenszyklus zu identifizieren, ohne die Gründe für ihr Auftreten herauszufinden, sowie die Korrektheit der Software in Bezug auf ihre Spezifikation festzustellen.

Diese Prozesse sind miteinander verknüpft und werden durch einen Begriff definiert – „Verifizierung und Validierung“ (V&V 7).

Die Verifizierung erfolgt:

• Überprüfung der Korrektheit der Übersetzung einzelner Komponenten in den Ausgabecode sowie Schnittstellenbeschreibungen durch Nachvollziehen der Beziehungen von Komponenten gemäß den spezifizierten Anforderungen des Kunden;
• Analyse der Korrektheit des Zugriffs auf Dateien oder Datenbanken unter Berücksichtigung der Verfahren, die in den Systemwerkzeugen zur Bearbeitung von Daten und zur Übermittlung von Ergebnissen verwendet werden;
• Überprüfung der Komponentenschutzmittel auf Einhaltung der Kundenanforderungen und deren Rückverfolgung.

Nach Prüfung der einzelnen Komponenten des Systems erfolgt deren Integration sowie Verifizierung und Validierung des integrierten Systems. Das System wird auf mehreren Testsuiten getestet, um festzustellen, ob die Testsuiten angemessen und ausreichend sind, um den Test abzuschließen und die Korrektheit des Systems festzustellen.

Die Idee, ein internationales Projekt zur formalen Verifizierung zu erstellen, wurde von T. Hoare vorgeschlagen und auf einem Symposium über verifizierte Software im Februar 2005 in Kalifornien diskutiert. Dann, im Oktober desselben Jahres, wurde auf der IFIP-Konferenz in Zürich ein internationales Projekt für die Dauer von 15 Jahren zur Entwicklung eines "ganzheitlichen automatisierten Werkzeugsatzes zur Überprüfung der Korrektheit von PS" verabschiedet.

Sie formulierte folgende Hauptaufgaben:

• Entwicklung einer einheitlichen Konstruktionstheorie und Analyse von Programmen;
• Aufbau eines umfassenden integrierten Satzes von Verifizierungswerkzeugen für alle Produktionsphasen, einschließlich der Entwicklung von Spezifikationen und ihrer Verifizierung, Generierung von Testfällen, Verfeinerung, Analyse und Verifizierung von Programmen;
• Erstellung einer Sammlung von formalen Spezifikationen und verifizierten Softwareobjekten verschiedene Typen und Typen.

Dieses Projekt geht davon aus, dass die Verifikation alle Aspekte der Erstellung und Überprüfung der Korrektheit von Software abdeckt und zu einem Allheilmittel für alle Probleme wird, die mit dem ständigen Auftreten von Fehlern in den zu erstellenden Programmen verbunden sind.

Viele formale Methoden zum Beweisen und Verifizieren spezifizierter Programme wurden in der Praxis erprobt. Fertig Großer Job Internationales Komitee ISO/IEC im Rahmen von ISO-Norm/ IEC 12207:2002 zur Standardisierung von Softwareverifizierungs- und -validierungsprozessen. Erfolgversprechend ist die Überprüfung der Korrektheit durch formale Methoden verschiedener Programmierobjekte.

Das Repository ist ein Repository von Programmen, Spezifikationen und Werkzeugen, die bei der Entwicklung und Erprobung, Bewertung von fertigen Komponenten, Werkzeugen und Methodenrohlingen verwendet werden. Es hat folgende allgemeine Aufgaben:

• Sammlung verifizierter Spezifikationen, Beweismethoden, Programmobjekte und Codeimplementierungen für komplexe Anwendungen;
• Akkumulation verschiedener Verifikationsmethoden, deren Gestaltung in geeigneter Form zur Suche und Auswahl einer realisierten theoretischen Idee für die weitere Anwendung;
• Entwicklung von Standardformularen zum Setzen und Austauschen von formalen Spezifikationen verschiedener Programmierobjekte sowie von Tools und vorgefertigten Systemen;
• Entwicklung von Interoperabilitäts- und Interaktionsmechanismen zum Übertragen fertig verifizierter Produkte aus dem Repository in neue verteilte und Netzwerkumgebungen, um neue PSs zu erstellen.

Dieses Projekt soll innerhalb von 50 Jahren entwickelt werden. Frühere Projekte haben ähnliche Ziele gesetzt: Verbesserung der Softwarequalität, Formalisierung von Servicemodellen, Reduzierung der Komplexität durch den Einsatz von PICs, Erstellung von Debugging-Tools zur visuellen Fehlerdiagnose und -beseitigung usw. Eine grundlegende Änderung der Programmierung im Sinne von visuelles Debugging oder beim Erreichen Hohe Qualität AN. Der Entwicklungsprozess geht weiter.

Ein neues internationales Softwareverifizierungsprojekt erfordert von seinen Teilnehmern nicht nur Wissen theoretische Aspekte Programmspezifikationen, sondern auch hochqualifizierte Programmierer für deren Umsetzung in den kommenden Jahren.