Agiles Testen (z.B. in Scrum, Kanban, XP) ist zu einem unverzichtbaren Bestandteil agiler Softwareentwicklung geworden.
Testen in agilen Entwicklungsprojekten unterscheidet sich vom klassischen Testen in erster Linie dadurch, dass Testen eine präventive Maßnahme ist und dass die Tests viel häufiger ausgeführt werden müssen. Der Fokus liegt dabei in der Einbindung von Testern unter Beachtung des agilen Manifests und der Anwendung agiler Prinzipien auf das Testen, wie beispielsweise schnelles Feedback, hoher Automatisierungsgrad, Auflösung starrer Teststufen, enge Zusammenarbeit in selbstorganisierten Teams.
Inhalt
- Definition
- Agiles Testen im Team
- Testkategorien
- Unit-Tests
- TDD/ATDD/BDD
- 3 Amigo
- Akzeptanztests
- Exploratives Testen
- Continuous Integration, Delivery & Deployment
- Integration in Scrum
- Genereller Umgang mit Bugs
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)Florian Wolters
German slides that give a overview about developer tests in the C++ programming language. It tries to underline the dependencies between software design, clean code, software quality and the software testing activity itself.
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017Torsten Kleiber
Oft fällt die Frage, ob man PL/SQL überhaupt automatisiert testen kann. Deshalb behandelt dieser Vortrag u.a. die folgenden Themen:
- Welche Fehler will ich mit Testautomatisierung überhaupt vermeiden?
- Änderung des Datenmodells
- Änderung bestehender Programme
- Datenbank-Patching/-Upgrade
- Wie sieht eigentlich mein Entwicklungsprozess aus?
- Wie viele Entwickler habe ich?
- Welches Wissen haben meine Entwickler?
- Muss ich branchen?
- Muss ich häufig meinen Code umstrukturieren?
- Welche Frameworks gibt es für die Testautomatisierung?
- SQL Developer
- Quest Code Tester
- utPLSQL
- ruby-plsql-spec
- Welche Voraussetzungen muss ich erfüllen?
- Datenbankversionen
- Infrastruktur
- Für welchen Zweck eignet sich welches Framework?
- Unterstützung von CI-Servern
- Unterstützung von Build Systemen wie z.B. Maven
- Test Driven Development
Neben der Theorie sehen Sie natürlich auch in Demo's, wie sich der Testcode "anfühlt".
Der Vortrag soll Ihnen eine Entscheidungsgrundlage liefern, ob Sie demnächst auch automatisch testen wollen und können!
Was ist eine Definition of Ready? Wozu benötigt man die DoR und was nützt sie? Welche Arten von DoRs gibt es? Welche Qualitäts-Kritieren sollten in einer DoR stehen? Wo muss die DoR im agilen Prozess positioniert werden? Wie kann ein agiles Requirements-Board die Definition und Qualitätssicherung von Anforderungen unterstützen?
Implementierung der Knowledge Engineering Workbench in myCBRAlexander Hundt
This is the presentation I held during the oral exam of my Bachelor Thesis.
The presentation is about where we can find expert knowledge around the internet and how we can excerpt this knowledge and use it as a basis for a Case-Based Reasoning system.
The second part of the thesis shows which principles of Software Engineering are used to implement an extraction prototype into a sophisticated development tool for CBR-systems.
The slides are provided in German.
Agiles Testen (z.B. in Scrum, Kanban, XP) ist zu einem unverzichtbaren Bestandteil agiler Softwareentwicklung geworden.
Testen in agilen Entwicklungsprojekten unterscheidet sich vom klassischen Testen in erster Linie dadurch, dass Testen eine präventive Maßnahme ist und dass die Tests viel häufiger ausgeführt werden müssen. Der Fokus liegt dabei in der Einbindung von Testern unter Beachtung des agilen Manifests und der Anwendung agiler Prinzipien auf das Testen, wie beispielsweise schnelles Feedback, hoher Automatisierungsgrad, Auflösung starrer Teststufen, enge Zusammenarbeit in selbstorganisierten Teams.
Inhalt
- Definition
- Agiles Testen im Team
- Testkategorien
- Unit-Tests
- TDD/ATDD/BDD
- 3 Amigo
- Akzeptanztests
- Exploratives Testen
- Continuous Integration, Delivery & Deployment
- Integration in Scrum
- Genereller Umgang mit Bugs
Automatisiertes Testen von Software in C++ (mit dem Test Framework Google Test)Florian Wolters
German slides that give a overview about developer tests in the C++ programming language. It tries to underline the dependencies between software design, clean code, software quality and the software testing activity itself.
Plsql drum test automatisiere, wer sich sich ewig bindet! - DOAG 2017Torsten Kleiber
Oft fällt die Frage, ob man PL/SQL überhaupt automatisiert testen kann. Deshalb behandelt dieser Vortrag u.a. die folgenden Themen:
- Welche Fehler will ich mit Testautomatisierung überhaupt vermeiden?
- Änderung des Datenmodells
- Änderung bestehender Programme
- Datenbank-Patching/-Upgrade
- Wie sieht eigentlich mein Entwicklungsprozess aus?
- Wie viele Entwickler habe ich?
- Welches Wissen haben meine Entwickler?
- Muss ich branchen?
- Muss ich häufig meinen Code umstrukturieren?
- Welche Frameworks gibt es für die Testautomatisierung?
- SQL Developer
- Quest Code Tester
- utPLSQL
- ruby-plsql-spec
- Welche Voraussetzungen muss ich erfüllen?
- Datenbankversionen
- Infrastruktur
- Für welchen Zweck eignet sich welches Framework?
- Unterstützung von CI-Servern
- Unterstützung von Build Systemen wie z.B. Maven
- Test Driven Development
Neben der Theorie sehen Sie natürlich auch in Demo's, wie sich der Testcode "anfühlt".
Der Vortrag soll Ihnen eine Entscheidungsgrundlage liefern, ob Sie demnächst auch automatisch testen wollen und können!
Was ist eine Definition of Ready? Wozu benötigt man die DoR und was nützt sie? Welche Arten von DoRs gibt es? Welche Qualitäts-Kritieren sollten in einer DoR stehen? Wo muss die DoR im agilen Prozess positioniert werden? Wie kann ein agiles Requirements-Board die Definition und Qualitätssicherung von Anforderungen unterstützen?
Implementierung der Knowledge Engineering Workbench in myCBRAlexander Hundt
This is the presentation I held during the oral exam of my Bachelor Thesis.
The presentation is about where we can find expert knowledge around the internet and how we can excerpt this knowledge and use it as a basis for a Case-Based Reasoning system.
The second part of the thesis shows which principles of Software Engineering are used to implement an extraction prototype into a sophisticated development tool for CBR-systems.
The slides are provided in German.
Qualitätssicherung in ADF Projekten der IKB Deutschen Industriebank AGTorsten Kleiber
Bei der Nutzung von ADF im Unternehmensumfeld wird man schnell erschlagen von der Fülle der Entscheidungen z. B. zu Architektur, zur Anwendung von Best Practices und Regeln.
Generell gilt das geflügelte Wort one size does not fit all: Jede der getroffenen Vorgaben ist für das Unternehmen, die Applikation oder sogar das einzelne Codefragment zu prüfen und zu hinterfragen. Die Nichtanwendung im Einzelfall sollte dokumentiert werden.
Wenn man sich denn einmal für einzuhaltende Regeln entschieden hat, wie prüft man diese an verschiedenen Stellen im Entwicklungsprozess? Wie sorgt man dafür, dass der Entwickler diese Regeln anwendet, ohne sich ständig weiterentwickelnde Entwicklerhandbücher durchlesen zu müssen?
Der Vortrag geht exemplarisch auf die in der ADF Entwicklung der IKB eingeführten Tools, Prozesse und Regeln ein, um eine qualitative Verbesserung der Code Basis zu erreichen und stellt genutzte Möglichkeiten zur Durchsetzung kritischer Regeln vor.
Bestandteile der aktuellen Lösung sind die Prüfung der Regeln im:
- JDeveloper mit
- Skripten für PMD, Findbugs und Checkstyle zur statischen Codeanalyse
- der integrierten Task View
- der JUnit Extension
- Skripten für JaCoCo zur Testabdeckung
- Continous Integration Server Jenkins mit den Plugins
- PMD, Findbugs und Checkstyle zur statischen Codeanalyse
- Task Scanner zur Prüfung offener Punkte
- Junit zur Testausführung
- JaCoCo zur Testabdeckung
Das Tool „ReqEdit“ vereinfacht den Workflow im Anforderungsmanagement zwischen Zulieferern und Kunden. Das Bearbeiten und Erstellen von Anforderungsdokumenten wird so einfach wie nie zuvor. Der unkomplizierte Datenaustausch zwischen verschiedenen Unternehmen wird sicher gestellt. ReqEdit ist zudem für kleine und mittlere Unternehmen geeignet und auch als Standalone Windows Client, mit dem offline gearbeitet werden kann, erhältlich.
Jedes IT-System stirbt irgendwann und muss durch ein neues System abgelöst werden. Solche Systemablösen bergen zahlreise Herausforderungen: Keine Doku, eine Technologie, die niemand mehr gut kennt, wissende Mitarbeiter sind nicht mehr greifbar, hoher Zeitdruck, großes Risiko im Betrieb etc. - oft eher Organtransplantation, als IT-Projekt.
Im Vortrag möchte ich meine Erfahrungen aus großen Systemablöseprojekten teilen. Wir werden uns ansehen, wie man Methoden aus Requirements Engineering und Reverse Engineering so kombiniert, dass alle notwendigen Anforderungen entdeckt werden. Wir werden sehen, dass die Zusammenarbeit zwischen Fachbereich und IT der kritische Erfolgsfaktor ist, wie man das am Besten organisiert und wie man Use Cases und ein Glossar dabei unterstützend einsetzt.
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertGFU Cyrus AG
In agilen Projekten ist funktionierende Software wichtiger als ausufernde Dokumentation. Durch kurze Entwicklungszyklen (Iterationen) werden den Anwendern schon während der Entwicklung Teilpakete der geplanten Softwarelösung mit einem sinnvollen Funktionsumfang bereit gestellt. In agilen Projekten ist die flexible Reaktion auf Änderungen der Anforderungen wichtiger als ein starrer Projektplan. Agilität bei der Entwicklung erfordert aber auch Agilität bei der Beschreibung der funktionalen Anforderungen (Requirements Engineering). Use Case-Modelle eignen sich hervorragend für diese Aufgabe. Durch dieses Vorgehen ist es möglich, Wünsche der Anwender, geänderte Rahmenbedingungen und Erfahrungen aus der bisherigen Entwicklung in der Realisierung zu berücksichtigen. Reinhard Brüggemeyer, Dozent dieses "Treffpunkt Semicolon", zeigt, warum in agilen Projekten der Anwender und seine Aufgaben im Mittelpunkt stehen. Pro und Contra des agilen Vorgehens gegenüber dem klassischen Requirements Engineering werden diskutiert.
Zum Testen von Software gehören sowohl das Aufspüren von Fehlern während der Entwicklung, als auch die Überprüfung des Gesamtproduktes. Das heißt, man sucht zunächst in einzelnen Codefragmenten nach Fehlern, und überprüft dann das Gesamtpaket auf seine Vollständigkeit und Korrektheit hin. Unzureichende oder unvollständige Dokumentationen führen häufig zu einer unzulänglichen Erfassung von fehlerfhaften Anforderungen. Dies fällt besonders bei sich wiederholenden und sich schnell verändernden PHP-Entwicklungen ins Gewicht. Der Grund dafür ist, dass PHP als nicht typisierte Sprache die Möglichkeit bietet, in hohem Tempo neue Funktionalitäten zu bestehender Software hinzuzufügen und zu ändern. Anwendungsteile, die mit PHP implementiert wurden, bedürfen keiner Neukompilierung. Die Genauigkeit des Gesamtkontextes kann noch während der Laufzeit des Prozesses geprüft werden. Des Weiteren muss auch sichergestellt werden, dass die Rückgabewerte von Methoden der Quellcode-Dokumentation bzw. dem erwarteten Typ entsprechen. In Projekten mit größeren Teams wird es häufig zur Wiederverwendung von Komponenten – oft auch in einem vom Software-Autor nicht erwarteten Kontext – kommen. Somit ist immer noch das Wichtigste nicht genannt: Sind neue Funktionen korrekt umgesetzt, und funktioniert die alte Funktionalität noch?
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Virtual Forge
Markus Theilen, bei EWE als IT-Koordinator zuständig für die Entwicklungskoordination, berichtet über seine Erfahrung und Vorgehensweise bei der Einführung von Virtual Forge CodeProfiler in der Anwendungsentwicklung von easy+
easy+ ist eine Eigenentwicklung von EWE auf Basis von SAP ERP 6.0, die die Komponenten Ablesung, Abrechnung, Fakturierung und Forderungsmanagement, Marktkommunikation und Reporting/Controlling für Energiedienstleistungen des EWE-Konzerns umfasst.
Applikationsmodernisierung: Der Weg von Legacy in die CloudAarno Aukia
Stell Dir vor: Du willst einen 6000er besteigen. Eine gute Vorbereitung, gutes Material und professionelles Wissen sind dabei unabdingbar.
Du schnappst Dir einen Berg-Guide, der Dich bei schwierigen Passagen unterstützt und Dir das passende Know-How weitergibt. Das schwere Material kannst Du auf ein Team aufteilen, das genau weiss, welche Pakete Du am sinnvollsten schnürst. Sie zeigen Dir zudem, welchen unnötigen Ballast Du abwerfen kannst.
Am Ende stehst Du am Ziel – Dich erwartet ein grossartiges Resultat und die Zufriedenheit des Vollbrachten.
Genau so fühlt sich die Reise Deiner Legacy Applikation an.
Im Webinar zeigen Dir die drei Partnerfirmen Object Engineering, Puzzle und VSHN, wie Du Deine Applikationen fit hältst. Dabei geben sie Dir einen Einblick, wie Experten die Applikationen analysieren, aufpeppen und den Betrieb sicherstellen können.
Regulatorics: Offside is when the referee whistles - DOAG 2018Torsten Kleiber
The regulatory system has more and more influence on our software development.
Regulatory authorities, external and internal Auditors are increasingly examining our IT and not longer only our business processes and balance sheets. Some of them have better trained IT experts as we can find on the free market.
General standards such as ISO/IEC 2700X but also banking-specific standards such as BAIT and MaRisk now pose challenges that generally only large software manufacturers know. Approximately 40 % of our projects are now regulatory-driven.
Therefore, we are currently redefining our development process in order to implement the following requirements, among others * Unchangeability of the tested artefacts after the test * Functional segregation * Detection of accidental changes or intentional manipulations of the application
The lecture shows the vision of such a safe process. It shows the current status of implementation in SOA and ADF development, for example:
Migration of version management to GIT in Atlassian BitBucket
Application and selection criteria for a branching model
Mandatory code reviews in Atlassian BitBucket
Build and Deployment Pipelines in Jenkins
Automatic documentation in JIRA Issue via Bitbucket and Jenkins.
Maybe you too can minimize the additional work and continue to work agile to meet such requirements.
Qualitätssicherung in ADF Projekten der IKB Deutschen Industriebank AGTorsten Kleiber
Bei der Nutzung von ADF im Unternehmensumfeld wird man schnell erschlagen von der Fülle der Entscheidungen z. B. zu Architektur, zur Anwendung von Best Practices und Regeln.
Generell gilt das geflügelte Wort one size does not fit all: Jede der getroffenen Vorgaben ist für das Unternehmen, die Applikation oder sogar das einzelne Codefragment zu prüfen und zu hinterfragen. Die Nichtanwendung im Einzelfall sollte dokumentiert werden.
Wenn man sich denn einmal für einzuhaltende Regeln entschieden hat, wie prüft man diese an verschiedenen Stellen im Entwicklungsprozess? Wie sorgt man dafür, dass der Entwickler diese Regeln anwendet, ohne sich ständig weiterentwickelnde Entwicklerhandbücher durchlesen zu müssen?
Der Vortrag geht exemplarisch auf die in der ADF Entwicklung der IKB eingeführten Tools, Prozesse und Regeln ein, um eine qualitative Verbesserung der Code Basis zu erreichen und stellt genutzte Möglichkeiten zur Durchsetzung kritischer Regeln vor.
Bestandteile der aktuellen Lösung sind die Prüfung der Regeln im:
- JDeveloper mit
- Skripten für PMD, Findbugs und Checkstyle zur statischen Codeanalyse
- der integrierten Task View
- der JUnit Extension
- Skripten für JaCoCo zur Testabdeckung
- Continous Integration Server Jenkins mit den Plugins
- PMD, Findbugs und Checkstyle zur statischen Codeanalyse
- Task Scanner zur Prüfung offener Punkte
- Junit zur Testausführung
- JaCoCo zur Testabdeckung
Das Tool „ReqEdit“ vereinfacht den Workflow im Anforderungsmanagement zwischen Zulieferern und Kunden. Das Bearbeiten und Erstellen von Anforderungsdokumenten wird so einfach wie nie zuvor. Der unkomplizierte Datenaustausch zwischen verschiedenen Unternehmen wird sicher gestellt. ReqEdit ist zudem für kleine und mittlere Unternehmen geeignet und auch als Standalone Windows Client, mit dem offline gearbeitet werden kann, erhältlich.
Jedes IT-System stirbt irgendwann und muss durch ein neues System abgelöst werden. Solche Systemablösen bergen zahlreise Herausforderungen: Keine Doku, eine Technologie, die niemand mehr gut kennt, wissende Mitarbeiter sind nicht mehr greifbar, hoher Zeitdruck, großes Risiko im Betrieb etc. - oft eher Organtransplantation, als IT-Projekt.
Im Vortrag möchte ich meine Erfahrungen aus großen Systemablöseprojekten teilen. Wir werden uns ansehen, wie man Methoden aus Requirements Engineering und Reverse Engineering so kombiniert, dass alle notwendigen Anforderungen entdeckt werden. Wir werden sehen, dass die Zusammenarbeit zwischen Fachbereich und IT der kritische Erfolgsfaktor ist, wie man das am Besten organisiert und wie man Use Cases und ein Glossar dabei unterstützend einsetzt.
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertGFU Cyrus AG
In agilen Projekten ist funktionierende Software wichtiger als ausufernde Dokumentation. Durch kurze Entwicklungszyklen (Iterationen) werden den Anwendern schon während der Entwicklung Teilpakete der geplanten Softwarelösung mit einem sinnvollen Funktionsumfang bereit gestellt. In agilen Projekten ist die flexible Reaktion auf Änderungen der Anforderungen wichtiger als ein starrer Projektplan. Agilität bei der Entwicklung erfordert aber auch Agilität bei der Beschreibung der funktionalen Anforderungen (Requirements Engineering). Use Case-Modelle eignen sich hervorragend für diese Aufgabe. Durch dieses Vorgehen ist es möglich, Wünsche der Anwender, geänderte Rahmenbedingungen und Erfahrungen aus der bisherigen Entwicklung in der Realisierung zu berücksichtigen. Reinhard Brüggemeyer, Dozent dieses "Treffpunkt Semicolon", zeigt, warum in agilen Projekten der Anwender und seine Aufgaben im Mittelpunkt stehen. Pro und Contra des agilen Vorgehens gegenüber dem klassischen Requirements Engineering werden diskutiert.
Zum Testen von Software gehören sowohl das Aufspüren von Fehlern während der Entwicklung, als auch die Überprüfung des Gesamtproduktes. Das heißt, man sucht zunächst in einzelnen Codefragmenten nach Fehlern, und überprüft dann das Gesamtpaket auf seine Vollständigkeit und Korrektheit hin. Unzureichende oder unvollständige Dokumentationen führen häufig zu einer unzulänglichen Erfassung von fehlerfhaften Anforderungen. Dies fällt besonders bei sich wiederholenden und sich schnell verändernden PHP-Entwicklungen ins Gewicht. Der Grund dafür ist, dass PHP als nicht typisierte Sprache die Möglichkeit bietet, in hohem Tempo neue Funktionalitäten zu bestehender Software hinzuzufügen und zu ändern. Anwendungsteile, die mit PHP implementiert wurden, bedürfen keiner Neukompilierung. Die Genauigkeit des Gesamtkontextes kann noch während der Laufzeit des Prozesses geprüft werden. Des Weiteren muss auch sichergestellt werden, dass die Rückgabewerte von Methoden der Quellcode-Dokumentation bzw. dem erwarteten Typ entsprechen. In Projekten mit größeren Teams wird es häufig zur Wiederverwendung von Komponenten – oft auch in einem vom Software-Autor nicht erwarteten Kontext – kommen. Somit ist immer noch das Wichtigste nicht genannt: Sind neue Funktionen korrekt umgesetzt, und funktioniert die alte Funktionalität noch?
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Virtual Forge
Markus Theilen, bei EWE als IT-Koordinator zuständig für die Entwicklungskoordination, berichtet über seine Erfahrung und Vorgehensweise bei der Einführung von Virtual Forge CodeProfiler in der Anwendungsentwicklung von easy+
easy+ ist eine Eigenentwicklung von EWE auf Basis von SAP ERP 6.0, die die Komponenten Ablesung, Abrechnung, Fakturierung und Forderungsmanagement, Marktkommunikation und Reporting/Controlling für Energiedienstleistungen des EWE-Konzerns umfasst.
Applikationsmodernisierung: Der Weg von Legacy in die CloudAarno Aukia
Stell Dir vor: Du willst einen 6000er besteigen. Eine gute Vorbereitung, gutes Material und professionelles Wissen sind dabei unabdingbar.
Du schnappst Dir einen Berg-Guide, der Dich bei schwierigen Passagen unterstützt und Dir das passende Know-How weitergibt. Das schwere Material kannst Du auf ein Team aufteilen, das genau weiss, welche Pakete Du am sinnvollsten schnürst. Sie zeigen Dir zudem, welchen unnötigen Ballast Du abwerfen kannst.
Am Ende stehst Du am Ziel – Dich erwartet ein grossartiges Resultat und die Zufriedenheit des Vollbrachten.
Genau so fühlt sich die Reise Deiner Legacy Applikation an.
Im Webinar zeigen Dir die drei Partnerfirmen Object Engineering, Puzzle und VSHN, wie Du Deine Applikationen fit hältst. Dabei geben sie Dir einen Einblick, wie Experten die Applikationen analysieren, aufpeppen und den Betrieb sicherstellen können.
Regulatorics: Offside is when the referee whistles - DOAG 2018Torsten Kleiber
The regulatory system has more and more influence on our software development.
Regulatory authorities, external and internal Auditors are increasingly examining our IT and not longer only our business processes and balance sheets. Some of them have better trained IT experts as we can find on the free market.
General standards such as ISO/IEC 2700X but also banking-specific standards such as BAIT and MaRisk now pose challenges that generally only large software manufacturers know. Approximately 40 % of our projects are now regulatory-driven.
Therefore, we are currently redefining our development process in order to implement the following requirements, among others * Unchangeability of the tested artefacts after the test * Functional segregation * Detection of accidental changes or intentional manipulations of the application
The lecture shows the vision of such a safe process. It shows the current status of implementation in SOA and ADF development, for example:
Migration of version management to GIT in Atlassian BitBucket
Application and selection criteria for a branching model
Mandatory code reviews in Atlassian BitBucket
Build and Deployment Pipelines in Jenkins
Automatic documentation in JIRA Issue via Bitbucket and Jenkins.
Maybe you too can minimize the additional work and continue to work agile to meet such requirements.
Regulatorics: Offside is when the referee whistles - DOAG 2018
DV Fragekatalog
1. • Erläutert die wesentlichen Kriterien eines Lastenhefts.
beschreibt die Gesamtheit der Forderungen des Auftraggebers an die Lieferungen und
Leistungen eines Auftragnehmers.
• Nennt die Zuständigkeit für Pflichten- bzw. Lastenheft.
Au f Grundlage des Lastenheftes wird das Pflichtenheft erstellt. Der Auftraggeber
sollte die Formulierungen in einem Lastenheft so allgemein und einschränkend wie
möglich formulieren. Das Pflichtenheft beschreibt wie der Auftragnehmer die
Anforderungen lösen möchte.
• Beschreibt Kriterien der Zielbestimmung in einem Pflichtenheft.
Musskriterien: für das Produkt unabdingbare Leistungen, die in jedem Fall erfüllt
werden müssen
Sollkriterie: Die Erfüllung dieser Kriterien wird angestrebt.
Kannkriterien: die Erfüllung ist nicht unbedingt nötig, sollte nur bei freien Kapazitäten
angestrebt werden.
Abgrenzungskriterien: diese Kriterien sollen bewusst nicht erreicht werden
• Beschreibt Kriterien des Produkteinsatzes in einem Pflichtenheft
1. Anwendungsbereiche
2. Zielgruppen
3. Betriebsbedingungen ( tägliche Betriebszeit, ständige Beobachtung des Systems
usw. )
• Erläutert das Kriterium Qualitätsanforderung
1. Ist die Summe aller Eigenschaften eines Objektes, Systems oder Prozesses.
2. Bewertet: die Güter alles …..
Qualitätsanforderung ist die Forderung die der Auftraggeber dem Auftraggeber
auferlegt. Das Produkt muss einer gewissen Norm (Güte) entsprechen und aus einer
bestimmten Qualität bestehen und auch fehlerfrei arbeiten.
• Nennt den Controller Chip, auf der die Arduino- Hardware
basiert.
ATmel Mega 328
• Nennt die englische Bezeichnung für eine Entwicklungsumgebung
IDE - Integrated Development Environment
• Interpretiert engl. Angaben zum Arduino Development
Environment richtig
Das Arduino-Entwicklungsumgebung enthält einen Text-Editor zum Schreiben
von Code, geschriebene Software wird Sketsch gennant.
• Nennt die eingesetzte Programmiersprache
C ist die eingesetzte Programmiersprache
• Ordnet die Begriffe Idiom und Patterns richtig zu.
IDIOMS : sind Sammlungen von einfachen Bausteinen die für den Anschluss von
2. Sensoren und Aktoren die nötig Bestandteile schnell verfügbar zu machen.
PLATTERNS: Das sind Lösungen für Probleme, die in ganz verschiedenen Projekten
auftauchen können.