IT-Berufe-Podcast – Détails, épisodes et analyse

Die Unterscheidung von Lastenheft und Pflichtenheft ist Thema der einhundertneunundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt Kurzübersicht Lastenheft

• Definition laut DIN 69901-5: „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.
• Verfasst von: Auftraggeber, also aus Sicht des Kunden.
• Inhalt: Lösungsneutrale funktionale und nicht-funktionale Anforderungen an ein Produkt, eine zu erstellende Software oder ein Projektergebnis aus Sicht des Auftraggebers.
• Fragen: WAS soll erreicht werden? WARUM ist das wichtig? WOFÜR wird das benötigt? WER will das haben?
• Ziel: Basis, um Angebote von potenziellen Auftragnehmern einzuholen. Es bildet die Grundlage für das vom Auftragnehmer zu erstellende Pflichtenheft.
• Rechtliche Relevanz: keine
• Mögliche Inhalte
  • Anforderungen der Stakeholder (z.B. Fachlichkeit, Regualatorik, Usability, Performance, Hardware-/Netwerk-/Softwareumgebung)
  • Ist-Zustand und Soll-Zustand
  • Abnahmekriterien für die Prüfung, ob die Anforderungen erfüllt sind
  • Einschränkungen bei zu verwendenden Technologien
  • Anforderungen an den Auftragnehmer (z.B. Zertifizierung)
  • Schnittstellen
  • Sonstige Anforderungen (z.B. Dauer, Kosten, Meilensteine)

Kurzübersicht Pflichtenheft

• Definition laut DIN 69901-5: „vom Auftragnehmer erarbeitete[n] Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“.
• Verfasst von: Auftragnehmer, also aus Sicht des Dienstleisters.
• Inhalt: Vorschlag für technische Lösung der Anforderungen aus dem Lastenheft.
• Fragen: WIE sollen die Anforderungen umgesetzt werden? WELCHE Technologien kommen zum Einsatz?
• Ziel: Konkretes Angebot eines Auftragnehmers, um die Anforderungen aus dem Lastenheft des Auftraggebers zu erfüllen. Basis für die Kalkulation von Kosten/Aufwänden und das Erstellen eines Angebots. Definiert die Vorgaben für die spätere Implementierung.
• Rechtliche Relevanz: wird Vertragsbestandteil und dient zur Abnahme der erbrachten Leistung
• Mögliche Inhalte
  • Spezifikationen des geplanten Ergebnisses bzw. die technische Realisierung, z.B. Architektur, Technologien, UML-Diagramme, ER-Modelle, geplante Prozessabläufe, UI-Entwürfe
  • Entwicklungsprozess, Projektplan mit Meilensteinen, Vorgaben zur Kommunikation
  • Ressourcen wie konkrete Personen, Subunternehmen, Technologien

Definitionen aus dem IT-Handbuch

Beginnen wir mit einer Definition der Begriffe. Dafür schaue ich immer gerne in das IT-Handbuch*, das bis vor einigen Jahren noch der „offizielle“ Prüfungsbegleiter war und als Nachschlagewerk mit in die Prüfung genommen werden durfte. Dort werden Lasten- und Pflichtenheft wie folgt definiert:

Lastenheft

Das Lastenheft enthält alle Forderungen des Auftraggebers (Kunden) an die Lieferungen und/oder Leistungen eines Auftragnehmers. Die Forderungen sind aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Diese sollten quantifizierbar und prüfbar sein. Im Lastenheft wird definiert, was für eine Aufgabe vorliegt und wofür diese zu lösen ist.

Pflichtenheft

Das Pflichtenheft enthält das vom Auftragnehmer erarbeitete Realisierungsvorhaben auf der Grundlage des Lastenheftes. Das Pflichtenheft enthält als Anlage das Lastenheft. Im Pflichtenheft werden die Anwendervorgaben detailliert und in einer Erweiterung die Realisierungsforderungen unter Berücksichtigung konkreter Lösungsansätze beschrieben. Im Pflichtenheft wird definiert, wie und womit die Forderungen zu realisieren sind.

Gut verständlich finde ich auch die Erläuterungen in der Wikipedia, die sich auf die DIN 69901 stützen (die leider nicht kostenfrei verfügbar ist):

Lastenheft

Gemäß DIN 69901-5 […] beschreibt das Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“. Das Lastenheft beschreibt in der Regel somit, was und wofür etwas gemacht werden soll. [Herv. d. Verf.]

Pflichtenheft

Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt – das sogenannte wie und womit. […] Laut DIN 69901-5 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“. [Herv. d. Verf.]

Vor- und Nachteile von Lasten- und Pflichtenheft

• Gute Planungssicherheit für den Auftraggeber. Er weiß genau, was er bekommt und wie teuer es wird.
• Eher starres Vorgehen ist nur geeignet für Projekte, die für einen langen Zeitraum unverändert bleiben (Wasserfallmodell).
• Das Erstellen der Dokumente ist sehr aufwändig und zeitintensiv.
• In agilen Vorgehensmodellen wie Scrum werden sie nicht verwendet.
• Alternative: Arbeit in Inkrementen, Minimum Viable Product

Relevanz für die Praxis und die IHK-Projektarbeit

Lasten- und Pflichtenheft sind zwei Artefakte, die ich in (fast) jeder IHK-Projektdokumentation erwarte. Da die Abschlussprojekte eine genaue Zeitvorgabe haben (40 bzw. 80 Stunden) und auch die Anforderungen zu Beginn komplett feststehen (sollten), eignen sich Lasten- und Pflichtenheft gut für die Dokumentation der Anforderungen.

Wenn man eine Priorisierung durchführen müsste, würde ich mehr Gewicht auf das Pflichtenheft legen, da dieses die Grundlage für den Vertrag zur Erstellung der Software ist. Das heißt, die Abnahme am Ende des Projekts erfolgt „gegen“ das Pflichtenheft. Was dort nicht enthalten ist, wird auch nicht umgesetzt.

Das ist übrigens auch eine häufige Frage im Fachgespräch: Warum ist das Pflichtenheft so wichtig? Weil es Vertragsbestandteil ist. Die Abgrenzung zwischen Lasten- und Pflichtenheft wird übrigens auch gerne als Prüfungsfrage (schriftlich und mündlich) genommen.

Aber auch im realen Leben haben Lasten- und Pflichtenheft ihre Daseinsberechtigung in bestimmten Projekten, z.B. wenn es um sicherheitskritische Produkte geht, die nicht „mal eben“ agil entwickelt werden können/dürfen.

Wer erstellt das Lasten- und Pflichtenheft?

Wie die Definitionen oben nahelegen, sollte im Rahmen des IHK-Abschlussprojekts das Lastenheft vom Kunden bzw. der Kundin erstellt werden und das Pflichtenheft vom Prüfling. Der/die Kund:in formuliert, was er/sie gerne hätte (also die fachlichen Anforderungen), und der Prüfling definiert die dazu passende konkrete technische Lösung.

In der Praxis ist es allerdings häufig so, dass Kunden ihre Anforderungen gar nicht genau kennen, geschweige denn sie so formulieren können, dass ein:e ITler:in sie versteht. Daher spricht nichts dagegen, dass Prüflinge schon beim Erstellen des Lastenhefts mitarbeiten.

Wenn du genau in die Zeitplanung von Gerdas und Markus‘ Dokumentation schaust, wirst du feststellen, dass bei uns im Unternehmen genau so gearbeitet wird. Es wurde nämlich im Rahmen der Projektplanung Zeit für die Unterstützung des Fachbereichs bei der Erstellung des Lastenhefts eingeplant. Die Entwickler:innen helfen den Kunden z.B. bei der Formulierung der Anforderungen, aber auch bei deren Identifikation. Gute Methoden dafür sind z.B. Brainstorming oder Interviews.

Aufbau und Formulierung

Zu Inhalt, Aufbau und (gerade für die Projektdokumentation interessant) Formulierung von Lasten- und Pflichtenheft gibt es keine harten Vorgaben. Letztlich bestehen beide Artefakte aus Prosa.

Lastenheft

Ich persönlich würde einen etwas „moderneren“ Ansatz wählen und im Lastenheft User-Storys verwenden (für Beispiele verweise ich wieder auf die beiden obigen Dokumentationen). Durch diese Vorgabe wird man bei der einheitlichen Formulierung unterstützt und muss sich nicht alles neu ausdenken.

Es gibt aber auch andere Ansätze, wie z.B. die richtig „enterprisey“ Volere-Templates. Da ist allein das Inhaltsverzeichnis aller möglichen Anforderungen schon ellenlang.

Pflichtenheft

Das Pflichtenheft sollte dann natürlich einige konkrete technische Artefakte beinhalten, da es ja so spezifisch wie möglich sein muss. Ich beschreibe es immer gerne so: Das Pflichtenheft muss man einem/einer Softwareentwickler:in ohne Kommentar auf den Tisch legen können und er/sie entwickelt dann allein auf dieser Basis die gewünschte Software. Dass das in der Praxis so nicht funktioniert (und auch nicht meine präferierte Umgangsweise ist) ist hoffentlich klar.

Man kann aber durchaus alle in der Entwurfsphase erstellten Artefakte ins Pflichtenheft packen: Use-Case-Diagramm, Klassendiagramm, Komponentendiagramm, ERM, Tabellenmodell, GUI-Mockups, Testszenarien usw. Wie gesagt: Was nicht im Pflichtenheft steht, wird nicht umgesetzt (und nicht bezahlt).

Berücksichtigung in der IHK-Projektdokumentation

Da sowohl Lasten-, als auch Pflichtenheft recht lang werden können, empfehle ich, in der Projektdokumentation ausschließlich Ausschnitte daraus abzubilden. Und damit meine ich nicht Deckblatt und Inhaltsverzeichnis (habe ich leider schon oft so gesehen), sondern die konkreten Anforderungen bzw. Lösungsvorschläge. Also zeig bitte interessante Inhalte und nicht unwichtigen Kram.

Da die Seiten in der Projektdokumentation begrenzt sind, kann man vielleicht sogar zwei Fliegen mit einer Klappe schlagen und Lasten-/Pflichtenheft sowie projektrelevante technische Inhalte daraus in nur einem Anhang zeigen. Beispiel: Das Pflichtenheft enthält ein Komponentendiagramm der geplanten Anwendung. Dann könnte der einseitige Auszug aus dem Pflichtenheft (die Seiten mit dem Komponentendiagramm) im Anhang der Dokumentation sowohl im Kapitel „Architektur“, als auch im Kapitel „Pflichtenheft“ referenziert werden. Einmal wird eben auf das Diagramm verwiesen und einmal auf das Pflichtenheft als erstelltes Artefakt.

Ich persönlich würde aber eher die für die Artefakte spezifischen Inhalte zeigen, also die formulierten Anforderungen. Denn das ist der eigentlich interessante Inhalt der beiden Dokumente im Rahmen der Projektdokumentation. Gerda und Markus haben das auch so gemacht.

Fazit

Lasten- und Pflichtenheft sind zwei wichtige Artefakte, die sowohl im richtigen Leben, als auch in der IHK-Abschlussprüfung relevant sind. Schau dir die Definitionen und einige Beispiele in Ruhe an und lerne sie auch für die Prüfung.

Literaturempfehlungen

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Was? Pflichtenheft und Lastenheft sind nicht dasselbe?
• DIN 69901 – Wikipedia
• Lastenheft – Wikipedia
• Pflichtenheft – Wikipedia

Um Teamarbeit bei der Softwareentwicklung geht es im Interview mit Christian Kranert in der einhundertachtundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt Vorstellung Christian Kranert

Christian hat sich schon in Episode 164 des Podcasts über Softwarequalität ausführlich vorgestellt, aber hier noch einmal die wichtigsten Eckdaten.

• Christian Kranert
• seit 17 Jahren in der IT und Softwareentwicklung tätig
• angefangen mit Visual Basic 6 auf Windows 95
• Ausbildung zum Fachinformatiker für Anwendungsentwicklung absolviert
• viel im SAP-Umfeld mit ABAP entwickelt
• inzwischen hauptsächlich mit C# unterwegs
• lebt und arbeitet in Nürnberg bei Head On Solutions GmbH
• entwickelt dort Cloud-Software für lokale Geschäfte wie Friseur-Studios zum Planen von Terminen, Kassieren, Buchhaltung usw.
• ist Abteilungsleiter mit eigenem Team

Teamarbeit in der Softwareentwicklung Warum brauchen wir Teamarbeit bei der Softwareentwicklung?

• bei der Komplexität heutiger Software ist es fast undenkbar, diese alleine zu entwickeln
• heutige Webanwendungen enthalten z.B. sehr viel UI-Entwicklung und sind im Backend und Frontend sehr komplex, Stichwort: Full Stack
• Christians Unternehmen hat ein eigenes Team ausgelagert nur für VueJS im Frontend
• durch das Team entsteht auch bessere Software
• wir wollen doch die „echte Welt“ übersetzen in Code und dort gibt es auch mehr als einen Benutzer
• gemeinsam zu entwickeln macht mehr Spaß, ist sozial, man kann voneinander lernen, man kann sich weiterentwickeln
• die interdisziplinäre Zusammenarbeit mit dem Fachbereich bzw. Kunden ist auch extrem wichtig

Wie sieht erfolgreiche interdisziplinäre Zusammenarbeiten zwischen dem IT-/Entwicklungs-Team und anderen Abteilungen aus?

• der Fachbereich erklärt den Entwickler:innen die Fachlichkeit
• Entwickler:innen dürfen/müssen das aber auch hinterfragen und ggfs. bessere Lösungen vorschlagen
• man sollte erst über das Problem reden und nicht schon über Lösung
• es muss die generelle Bereitschaft zur Teamarbeit vorhanden sein und eine entsprechende Kultur

Welche Prozessmodelle (z.B. Wasserfall, Scrum) unterstützen/behindern die Teamarbeit?

• das klassische Wasserfallmodell ist eher hierarchisch aufgebaut mit Lasten-/Pflichtenheft und passt nicht so gut zur Teamarbeit
• Scrum ist aber auch kein Allheilmittel
• das Daily ist sehr wichtig, denn Kommunikation ist der Schlüssel zu erfolgreicher Teamarbeit

Wie sieht richtig gute Teamarbeit in der Softwareentwicklung aus?

• Kommunikation ist das A und O, z.B. wenn ein Feature fertig ist, damit die Kolleg:innen darauf aufsetzen können
• alle Teammitglieder:innen sollten auch aktiv Hilfe anbieten und einfordern
• die gesamte Softwareentwicklung ist Teamarbeit und die geht schon mit der Produktidee los
• dabei kann es helfen, verschiedene Perspektiven einzunehmen, um ein besseres Bild der Anforderungen zu bekommen
• auch weitere Aufgaben lassen sich besser im Team lösen: Risiken abschätzen, Prioritäten ableiten, Product Backlog füllen
• wenn das Verhältnis von Kosten und Nutzen passt, startet die Implementierung und Aufgaben werden im Team verteilt
• in Christians Team werden Konzepte z.B. gemeinsam erarbeitet, ganz einfach in OneNote*
• das Team startet mit einem Datenmodell als Diskussionsgrundlage und legt dann die Datentypen fest
• außerdem werden Mockups erstellt, um darüber gemeinsam zu diskutieren
• sehr wichtig ist auch das gemeinsame Festlegen von Namen im Team, denn viele Köpfe haben mehr (fachliches) Wissen als einer alleine
• der große Vorteil bei dieser Vorgehensweise ist, dass früh erkannte Fehler bei Anpassungen wenig kosten im Vergleich zu späteren Projektphasen, wenn alles schon umgesetzt ist

Warum ist die Teamkultur nicht nur beim Code Review wichtig und wie sieht sie aus?

• Christians Team entwickelt oft im Pair Programming zusammen und führt danach noch Code Reviews durch
• hier war oft insb. beim Testen die Einstellung, dass das doch jemand anders macht und nicht die Aufgabe der Softwareentwickler:innen sei
• aber gerade beim Testen ist die Abstimmung mit den Tester:innen wichtig, damit man nicht den kompletten Code umschreiben muss, wenn man am Test vorbei entwickelt hat

Wie stellt man sicher, dass alle Teammitglieder:innen sich aktiv einbringen und wie kann eine Führungskraft Teamarbeit fördern/behindern?

• die Führungskraft ist sehr wichtig, denn ihre zentrale Aufgabe ist die Pflege der Teamkultur
• die häufig anzutreffene Skepsis bei Entwickler:innen gegenüber Meetings muss von der Führungskraft abgebaut werden
• Meetings müssen aber natürlich auch einen Mehrwert für alle Teilnehmer:innen bieten und müssen vernünftig geplant und vorbereitet werden
• auch für Entwickler:innen sind Meetings wichtig, da sie helfen, offene Fragen zu klären und Entscheidungen herbeizuführen
• Teamarbeit kann die Teammitglieder:innen motivieren, wenn man gemeinsam eine gute Lösung findet und z.B. eine „harte Nuss“ knackt

Braucht ein Team eine Leitung?

• das kommt stark auf das Team an

Storming, Forming, Norming, Performing: gibt es das wirklich in der Praxis?

• Christian hat das mal in einem Buch gelesen, aber nur dunkel in Erinnerung
• in der Praxis durchlaufen die Teams diese Phasen wohl tatsächlich, aber intuitiv verhalten sich die Mitglieder:innen meist den Phasen entsprechend

Wie sieht häufig die (negative) Realität in Sachen Teamarbeit aus bzw. an welchen Fehlern scheitert Teamarbeit häufig?

• Juniors werden vernachlässigt und bekommen keine oder zu wenig Unterstützung
• Hierarchiedenken, gerade wenn Softwareentwicklung nicht das Kerngeschäft des Unternehmens ist
• Introvertiertheit der Teammitglieder:innen
• aber auch Extrovertiertheit bzw. Egozentrik bei Teammitglieder:innen
• Mangel an Diversität im Team

Wie wird man als Entwickler:in „teamfähig“?

• Persönlichkeitsentwicklung! dazu gibt es viele gute Bücher
• eine fördernde und fordernde Führungskraft ist wichtig für das Empowerment der Teammitglieder:innen
• die Führungskraft sollte z.B. One-on-Ones mit Mitarbeitenden führen, immer wieder nachfragen und auch die eigene Entwicklung aufzeigen
• loben und wertschätzen sollten bei jeder Führungskraft dazu gehören
• Empathie ist auch wichtig
• Konflikte sollten schnell gelöst werden

Wie wichtig ist eine gute Fehlerkultur?

• sehr wichtig
• Fehler müssen erlaubt sein und dürfen nicht „geahndet“ werden
• aber was ist eigentlich ein Fehler? Schludrigkeit ist sicherlich kein Fehler
• Checklisten können helfen, eine gewisse Basisqualität sicherzustellen

Wie können schon Azubis in die Teamarbeit integriert werden?

• einfach mal loslegen und sie an die Hand nehmen
• Azubis direkt in echte Projekte einbinden, aber ohne harten Deadlines oder großes Fehlerpotential
• viel loben
• Checklisten helfen auch hier beim Einstieg

Was sind die Folgen, wenn nicht im Team gearbeitet wird?

• Christian hat noch nie jemanden kennengelernt, der/die sich aktiv gewehrt hat gegen Teamarbeit
• eher haben die Kolleg:innen evtl. Angst mitzumachen
• den berühmten „10x-Develover“ gibt es nicht, aber Seniors können als Multiplikatoren im Team wirken und Juniors voranbringen und damit das gesamte Team

Wie/wo kann man dich erreichen?

• LinkedIn

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Qualitätssicherung bei der Softwareentwicklung mit Christian Kranert
• Christian Kranert bei LinkedIn
• Head-on Solutions GmbH bei LinkedIn

Um den Aufbau und den Ablauf der Abschlussprüfung in den IT-Berufen geht es in der einhundertachzigsten Episode des IT-Berufe-Pocasts.

Inhalt

• Die Teile der Abschlussprüfung sollten allen Auszubildenden und Ausbilder:innen geläufig sein, da die drei Jahre der Ausbildung hauptsächlich auf diese Prüfung hinarbeiten.
• Der Aufbau der Abschlussprüfung ist für alle IT-Berufe identisch, die Inhalte unterscheiden sich aber natürlich. Insbesondere die Dauer und die Inhalte der Projektarbeit sind berufsspezifisch.
• Es gibt insgesamt 7 verschiedene IT-Berufe.
  • Fachinformatiker:in
    • Anwendungsentwicklung
    • Systemintegration
    • Daten- und Prozessanalyse
    • Digitale Vernetzung
  • IT-System-Elektroniker:in
  • Kauf­mann/Kauffrau für Digitalisierungsmanagement
  • Kaufmann/Kauffrau für IT-System-Management
• Der Großteil (60%) der Inhalte der schriftlichen Prüfung (GAP Teil 1 und WiSo) ist für alle Berufe gleich.
• Achtung: Die IHK-Prüfungen sind bundesweit einheitlich, aber in Baden-Württemberg laufen sie anders als in den übrigen 15 Bundesländern. Die folgenden Ausführungen gelten daher ggfs. nicht für Prüfungen in Baden-Württemberg.

Aufbau der Abschlussprüfung

Wer es ganz genau wissen will, schaut am besten in die jeweilige Berufsverordnung:

• Fachinformatiker:in Anwendungsentwicklung
• Fachinformatiker:in Systemintegration
• Fachinformatiker:in Daten- und Prozessanalyse
• Fachinformatiker:in Digitale Vernetzung
• IT-System-Elektroniker:in
• Kauf­mann/Kauffrau für Digitalisierungsmanagement
• Kaufmann/Kauffrau für IT-System-Management

Die folgenden Zitate stammen aus der FIAusbV.

Teil 1 (der gestreckten Abschlussprüfung)

Teil 1 der gestreckten Abschlussprüfung findet im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes statt. Dieser Prüfungsteil ist für alle IT-Berufe identisch.

Im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes hat der Prüfling nachzuweisen, dass er in der Lage ist,
1. Kundenbedarfe zielgruppengerecht zu ermitteln,
2. Hard- und Software auszuwählen und ihre Beschaffung einzuleiten,
3. einen IT-Arbeitsplatz zu konfigurieren und zu testen und dabei die Bestimmungen und die betrieblichen Vorgaben zum Datenschutz, zur IT-Sicherheit und zur Qualitätssicherung einzuhalten,
4. Kunden und Kundinnen in die Nutzung des Arbeitsplatzes einzuweisen und
5. die Leistungserbringung zu kontrollieren und zu protokollieren.
(FIAusbV §9 Abs. 2)

Teil 1 der Prüfung ist eine schriftliche Prüfung über 90 Minuten, die nach 18 Monaten der Ausbildung absolviert werden muss. Inhalt sind alle im Ausbildungsrahmenplan (Teil der oben verlinkten Ausbildungsverordnung) und Rahmenlehrplan (für die Berufsschulen) bis zu diesem Zeitpunkt zu vermittelnden Inhalte.

• Rahmenlehrplan für die Ausbildungsberufe Fachinformatiker und Fachinformatikerin sowie IT-System-Elektroniker und IT-System-Elektronikerin
• Rahmenlehrplan für die Ausbildungsberufe Kaufmann für IT-System-Management, Kauffrau für IT-System-Management Kaufmann für Digitalisierungsmanagement sowie Kauffrau für Digitalisierungsmanagement

Das Ergebnis des ersten Prüfungsteils geht zu 20% in die Abschlussnote ein.

Tipps zur Vorbereitung auf die Prüfung gibt es in meinen entsprechenden Podcast-Episoden, z.B. Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe. Und hier habe ich eine große Liste mit allen potentiellen Prüfungsthemen für dich zusammengestellt: Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen.

Teil 2 (der gestreckten Abschlussprüfung)

In Teil 2 der Prüfung sollen die bereits in Teil 1 abgefragten Inhalte nicht explizit erneut abgefragt werden, sie werden aber als bekannt vorausgesetzt.

Teil 2 der Prüfung teilt sich in vier konkrete Prüfungsteile auf:

• Projektarbeit
• Zwei fachspezifische schriftliche Prüfungen
• Wirtschaft- und Sozialkunde

Betriebliche Projektarbeit

Die betriebliche Projektarbeit ist in allen IT-Berufen durchzuführen. Sie unterscheidet sich aber je nach Beruf und Fachgebiet. Für die Umsetzung stehen 40 Stunden zur Verfügung, aber Anwendungsentwickler:innen haben 80 Stunden.

Der Prüfling hat eine betriebliche Projektarbeit durchzuführen und mit praxisbezogenen Unterlagen zu dokumentieren.
Vor der Durchführung der betrieblichen Projektarbeit hat er dem Prüfungsausschuss eine Projektbeschreibung zur Genehmigung vorzulegen.
In der Projektbeschreibung hat er die Ausgangssituation und das Projektziel zu beschreiben und eine Zeitplanung aufzustellen.
Die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagen höchstens 80 Stunden.
(FIAusbV §12 Abs. 2)

Zusätzlich zur Umsetzung der Projektarbeit und ihrer Dokumentation muss ein Prüfling in diesem Prüfungsteil nachweisen, dass er/sie in der Lage ist…

1. die Arbeitsergebnisse adressatengerecht zu präsentieren und
2. seine Vorgehensweise bei der Durchführung der betrieblichen Projektarbeit zu begründen
   (FIAusbV §12 Abs. 3)

Das heißt, es werden eine Projektpräsentation und ein anschließendes Fachgespräch durchgeführt. Dabei gilt:

Die Prüfungszeit beträgt insgesamt höchstens 30 Minuten.
Die Präsentation soll höchstens 15 Minuten dauern.
(FIAusbV §12 Abs. 3)

Die Gewichtung der einzelnen Prüfungsteile sieht so aus:

• Projektdokumentation: 50%
• Projektpräsentation und Fachgespräch: 50% (nur eine gemeinsame Note ohne Unterscheidung der beiden Teile)

Fachspezifische schriftliche Prüfung

Dieser Prüfungsteil ist für alle IT-Berufe unterschiedlich und fachspezifisch. Es werden zwei schriftliche Prüfungen zu je 90 Minuten geschrieben.

Die Themengebiete für die einzelnen Berufe sind:

• Fachinformatiker:in Anwendungsentwicklung
  • Planen eines Softwareproduktes
  • Entwicklung und Umsetzung von Algorithmen
• Fachinformatiker:in Systemintegration
  • Konzeption und Administration von IT-Systemen
  • Analyse und Entwicklung von Netzwerken
• Fachinformatiker:in Daten- und Prozessanalyse
  • Durchführen einer Prozessanalyse
  • Sicherstellen der Datenqualität
• Fachinformatiker:in Digitale Vernetzung
  • Diagnose und Störungsbeseitigung in vernetzten Systemen
  • Betrieb und Erweiterung von vernetzten Systemen
• IT-System-Elektroniker:in
  • Installation von und Service an IT-Geräten, IT-Systemen und IT-Infrastrukturen
  • Anbindung von Geräten, Systemen und Betriebsmitteln an die Stromversorgung
• Kauf­mann/Kauffrau für Digitalisierungsmanagement
  • Entwicklung eines digitalen Geschäftsmodells
  • Kaufmännische Unterstützungsprozesse
• Kaufmann/Kauffrau für IT-System-Management
  • Einführen einer IT-Systemlösung
  • Kaufmännische Unterstützungsprozesse

Beide Prüfungen werden mit jeweils 10% in die Endnote eingerechnet. Die Aufgaben sind schriftlich zu beantworten und werden manuell von Prüfer:innen korrigiert.

Wirtschaft- und Sozialkunde (WiSo)

Im letzten Prüfungsteil soll der Prüfling nachweisen, dass er in der Lage ist…

allgemeine wirtschaftliche und gesellschaftliche Zusammenhänge der Berufs- und Arbeitswelt darzustellen und zu beurteilen.
(FIAusbV §15 Abs. 1)

Diese schriftliche Prüfung dauert 60 Minuten und geht zu 10% in die Abschlussnote ein. Die Aufgaben sind durch Ankreuzen oder Eintragen von Zahlen zu beantworten und werden automatisiert korrigiert.

Gewichtung der Prüfungsteile

Die obigen Prüfungsteile gehen mit folgenden Gewichtungen in die Endnote ein (siehe FIAusbV §16 Abs. 1)

• Einrichten eines IT-gestützten Arbeitsplatzes (GAP Teil 1): 20%
• Betriebliche Projektarbeit: 50%
  • Davon 50% für die Projektdokumentation und 50% gemeinsam für Projektpräsentation und Fachgespräch
• Fachspezifische schriftliche Prüfung: jeweils 10%
• Wirtschafts- und Sozialkunde: 10%

Somit zählen alle schriftlichen Prüfungen zusammen 50% der Abschlussnote und das Projekt auch 50%. Die Hälfte der Punkte liegt damit in der Hand der Prüflinge, da sie ihr Abschlussprojekt selbst auswählen, planen und durchführen können.

Nicht-Bestehen der Prüfung

Die Abschlussprüfung ist bestanden, wenn die genannten Prüfungsleistungen wie folgt bewertet worden sind (siehe FIAusbV §16 Abs. 2):

• im Gesamtergebnis von Teil 1 und Teil 2 mindestens „ausreichend“ (also 50%)
• im Ergebnis von Teil 2 mindestens „ausreichend“ (also 50%)
• in mindestens drei Prüfungsbereichen von Teil 2 mindestens „ausreichend“ (also 50%)
• in keinem Prüfungsbereich von Teil 2 „ungenügend“ (also mind. 30%)

Das heißt, dass man quasi in Teil 1 der Prüfung nicht „durchfallen“ kann (sofern man die Note mit Teil 2 ausgleichen kann).

Ggfs. kannst du ein schlechtes Ergebnis im schriftlichen Teil 2 der Prüfung durch eine mündliche Ergänzungsprüfung ausgleichen.

Es gibt einen hervorragenden Notenrechner für die IT-Abschlussprüfung (AO2020).

Ablauf der Abschlussprüfung

Es gibt für Teil 1 der Prüfung eine Prüfung im Frühjahr und eine im Herbst, sowie für Teil 2 eine Sommer- und eine Winterprüfung. Die weitaus meisten Prüflinge nehmen an der Frühjahrs- bzw. Sommerprüfung teil. Auszubildende mit verkürzter Ausbildungszeit, duale Studierende oder Umschüler nehmen meist an der Herbst- bzw. Winterprüfung teil.

Die folgenden Termine sind grobe Richtwerte. Nur die Termine der schriftlichen Prüfungen werden deutschlandweit (bis auf Baden-Württemberg) einheitlich von der Aufgabenstelle für kaufmännische Abschluss- und Zwischenprüfungen festgelegt. Die anderen Termine bestimmen die örtlichen IHKen individuell. Meist werden die Noten den Prüflingen nicht vom Prüfungsausschuss mitgeteilt, sondern sie werden nach der Prüfung durch die IHK per Post versendet.

• Termine (Vgl. Termine der schriftlichen Abschlussprüfungen)
  • Teil 1: Februar/März (Frühjahr) bzw. September/Oktober (Herbst)
  • Teil 2: April/Mai (Sommer) bzw. November/Dezember (Winter)
  • Mündliche Prüfung (Präsentation/Fachgespräch): Mai/Juni/Juli (Sommer) bzw. Dezember/Januar (Winter)
• Betriebliche Projektarbeit
  • Abgabe des Antrags: Februar (Sommer) bzw. September (Winter)
  • Bearbeitungszeit: ab Genehmigung des Antrags durch den Prüfungsausschuss (meist einige Wochen nach Antragsstellung) bis zu einem festgelegten Termin
  • Abgabe der Dokumentation: meist eine Woche nach der schriftlichen Prüfung Teil 2
• Mitteilung der Prüfungsergebnisse
  • Teil 1: einige Wochen nach dem Prüfungstermin
  • Teil 2: einige Wochen nach dem Prüfungstermin, jedoch meist vor der mündlichen Prüfung
  • mündliche Prüfung: am Tag der mündlichen Prüfung
  • Gesamtergebnis: am Tag der mündlichen Prüfung

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Berufsverordnungen
  • FIAusbV: Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin
  • ITSEAusbV: Verordnung über die Berufsausbildung zum IT-System-Elektroniker und zur IT-System-Elektronikerin
  • DigiManKflAusbV: Verordnung über die Berufsausbildung zum Kaufmann für Digitalisierungsmanagement und zur Kauffrau für Digitalisierungsmanagement
  • ITSManKflAusbV: Verordnung über die Berufsausbildung zum Kaufmann für IT-System-Management und zur Kauffrau für IT-System-Management
• Rahmenlehrpläne
  • Rahmenlehrplan für die Ausbildungsberufe Fachinformatiker und Fachinformatikerin sowie IT-System-Elektroniker und IT-System-Elektronikerin (Beschluss der Kultusministerkonferenz vom 13.12.2019)
  • Rahmenlehrplan für die Ausbildungsberufe Kaufmann für IT-System-Management, Kauffrau für IT-System-Management Kaufmann für Digitalisierungsmanagement sowie Kauffrau für Digitalisierungsmanagement
• Prüfungsvorbereitung auf Teil 1
  • Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe
  • Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen
• Notenrechner für die IT-Abschlussprüfung (AO2020)
• Termine der schriftlichen Abschlussprüfungen
• Ablauf der mündlichen Ergänzungsprüfung

Nach langer Zeit setze ich meine Reihe der Lernzielkontrollen zur Programmierung mit einem wichtigen Thema fort. Arrays und Listen sind der Inhalt der neunundneunzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Was ist ein Array?
  • Eine Liste mehrerer Werte des gleichen Datentyps.
• Wie findet man heraus, wie viele Elemente ein Array enthält?
  • Arrays haben eine Eigenschaft „Länge“, die in Java z.B. length heißt.
• Wie kann man die Länge eines Arrays verändern?
  • Gar nicht. Arrays sind nicht redimensionierbar.
• Wie greift man auf die Elemente in einem Array zu?
  • Viele Programmiersprachen bieten für den Zugriff auf die Elemente eines Arrays die Schreibweise mit eckigen Klammern an, z.B. myArray[2]. Der Index ist meistens 0-basiert.
• Wie iteriert man über die Elemente eines Arrays?
  • Mit Schleifen wie der for-Schleife. Einige Programmiersprachen bieten auch eine foreach-Schleife (in Java „extended for“) an, die ohne Indizes arbeitet und nur die Elemente durchläuft.
• Was ist eine foreach-Schleife?
  • Sie durchläuft alle Elemente eines Arrays und weist sie nach und nach einer Iterationsvariablen zu. Dadurch muss sich der Entwickler nicht um die Indizes kümmern.
• Was ist ein mehrdimensionales Array?
  • Ein Array kann nicht nur eine Dimension haben, sondern mehrere. Bis zur dritten kann man sich dieses Konstrukt noch vorstellen (2. Tabelle, 3. Würfel).
• Was ist ein assoziatives Array?
  • Ein zweidimensionales Array, das anstatt numerischer Indizes beliebige Datentypen als Schlüssel zulässt.
• Was ist eine Liste?
  • Eine Liste ist quasi ein intelligentes Array. Sie stellt Funktionen zur Manipulation bereit und ist redimensionierbar.
• Was unterscheidet eine verkettete Liste (LinkedList) von einer Array-Liste (ArrayList)?
  • Die Art der Implementierung. Verkettete Listen sind schnell beim Einfügen und langsam beim Zugriff, Array-Listen sind langsam beim Einfügen und schnell beim Zugriff.
• Wann sollte man Arrays und wann Listen verwenden?
  • Wenn es keinen guten Grund dagegen gibt, sollte man immer Listen verwenden, da sie deutlich einfacher zu verwenden sind und zahlreiche Funktionen bereitstellen.
• Was ist ein Set?
  • Eine Liste mit eindeutigen Elementen.
• Was ist eine Map?
  • Das gleiche wie ein assoziatives Array, aber als eigene Datenstruktur implementiert. Es handelt sich um Schlüssel/Wert-Paare auf die über die Schlüssel zugegriffen werden kann.

Literaturempfehlungen

Eine sehr ausführliche Einführung in Listen und andere Datenstrukturen aus der Collection-API bietet die gute alte Java-Insel*.

http://fiae.link/JavaInsel*
(direkt beim Rheinwerk-Verlag bestellen*) Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Arrays
• Listen
• Assoziative Speicher

Das äußerst empfehlenswerte Buch „Pragmatic Unit Testing in Java 8 with JUnit“ wird im Buchclub in der achtundneunzigsten Episode des Anwendungsentwickler-Podcasts besprochen.

Inhalt

Das Buch ist meine absolute Empfehlung für jeden Azubi. Meine eigenen Azubis lesen es schon direkt im 1. Ausbildungsjahr, kurz nachdem sie ihre ersten Java-Aufgaben gelöst haben. Für mich gehört Unit-Testing einfach mit zur Ausbildung dazu und man kann gar nicht früh genug damit anfangen.

Bislang waren die Rückmeldungen zum Buch sehr positiv. Alle Azubis haben es gut verstanden und konnten die Inhalte auch direkt in die Praxis umsetzen. Wir haben uns für das Durcharbeiten meistens ca. 2 Wochen Zeit genommen. Das Buch ist sehr verständlich geschrieben, enthält tolle Beispiele – und zwar endlich einmal auch in Java 8 – und ist dank des geringen Umfangs von knapp 200 Seiten sehr schnell zu lesen.

Die Bücher aus dem Hause Pragmatic Programmers kann man eigentlich ausnahmslos empfehlen. Sie haben u.a. auch das „Standardwerk“ zum Einstieg in Ruby on Rails* oder POODR* veröffentlicht. Pragmatic Unit Testing in Java 8 with JUnit* reiht sich – meiner Meinung nach – hier perfekt ein.

Grundlagen

Das Buch führt auf knapp 50 Seiten zunächst in das Thema Unit-Tests ein und erklärt die Funktionsweise von JUnit. Schritt für Schritt wird ein lauffähiger Unit-Test erstellt und dabei werden auch die neuen Entwicklungen in JUnit berücksichtigt – also keine alten test*-Methoden mehr, sondern vernünftige Annotations. Dabei wird auch gleich das berühmte AAA zum Aufbau der Test-Methoden erläutert und @Before und @After eingeführt.

Ich kann mir in Zukunft meine eigenen Erklärungen sparen und lasse meine Azubis diese ersten 50 Seiten lesen. Danach sollten sie alle wichtigen Begriffe und Ideen zum Thema Unit-Tests und Junit kennen 🙂

Das Buch startet mit einem schönen Überblick, warum man überhaupt testen sollte. Außerdem enthält es Schritt-für-Schritt-Anleitungen, um Unit-Test mit Eclipse zu erstellen. Im Anhang wird aber auch auf IntelliJ und Netbeans eingegangen, sodass man unabhängig von der konkreten IDE mitmachen kann. Die zu testenden Codebeispiele werden ebenfalls ausführlich erläutert. Es können also auch absolute Anfänger mitarbeiten.

Als nächstes werden Assertions im Detail vorgestellt. Auch die Hamcrest-Matcher gehören dazu, um sprechende Tests zu schreiben, und die unterschiedlichen Möglichkeiten z.B. mittels Annotationen werden vorgestellt.

Akronyme

Der nächste Teil (ca. 40 Seiten) ist dann ganz den „Mnemonics“ gewidmet. Das hilft in der Praxis, ist aber nicht prüfungsrelevant.

• FIRST: fast, isolated, repeatable, self-validating, timely.
• Right-BICEP: right, boundary conditions, inverse relationships, cross-checking, error conditions, performance.
• CORRECT: conformance, ordering, range, reference, existence, cardinality, time.

Anhand dieser einprägsamen Akronyme geht Jeff Langr die Eigenschaften guter Unit-Tests durch und bringt den Lesern damit gleich bei, worauf sie bei der Programmierung ihrer Tests achten sollten, um keine falsche Sicherheit zu erreichen.

Design

Im dritten Teil (ca. 60 Seiten) widmet sich das Buch den „großen“ Themen Refactoring und Mock-Objekte. Es wird intensiv geschildert, warum Refactoring wichtig ist und warum Unit-Tests unabdingbare Voraussetzung für das Refactoring des eigenen Codes sind. Außerdem wird erklärt, wofür man Mock-Objekte braucht und wann man sie besser nicht einsetzen sollte.

Das Kapitel wird abgerundet mit einer stimmigen Liste von Test Smells, die auf ein nötiges Refactoring des Test-Codes hindeuten. Somit wird dem Leser gleich an die Hand gegeben, dass auch der Test-Code den gleichen Qualitätskriterien genügen sollte wie der Produktivcode. Sogar ein Kurzausflug in die SOLID-Prinzipien ist enthalten.

Als nächstes werden Mock-Objekte vorgestellt und die Unterschiede zwischen Stubs und Mocks erläutert. Der Teil schließt mit einem Kapitel zum Refactoring des Test-Codes. Das ist ein Vorgang, der zu jedem testgetriebenen Entwicklungsprozess gehören sollte.

Big Picture

Der letzte Teil des Buchs (ca. 50 Seiten) geht dann konkret auf Test Driven Development ein und auch auf das Testen schwieriger Probleme wie zum Beispiel Multithreading und Datenbanken. Ganz zum Schluss werden dann auch noch weitere wichtige Begriffe erläutert wie z.B. Continuous Integration und Code Coverage. Es ist also auch etwas für fortgeschrittene Tester dabei.

Fazit

Ich konnte Pragmatic Unit Testing in Java 8 with JUnit* gut von vorn bis hinten durchlesen. Es ist durchgängig interessant geschrieben und enthält viele lehrreiche Tipps. Es ist daher meine Empfehlung für alle Azubis (oder auch Ausbilder 😉 ), die sich dem Thema Unit-Tests widmen möchten (oder müssen). Es gehört für mich ab sofort zur Standardbibliothek für meine Azubis.

Tipp für Ausbilder

Ich würde neuen Auszubildenden das Buch nach ca. drei Monaten Einarbeitung zur Lektüre empfehlen. Dann sollten sie bereits einige (negative) Erfahrungen mit der Programmierung gemacht haben und schnell einsehen, warum automatische Tests so wichtig sind. Die Java-Vorkenntnisse sollten dann auch ausreichen, um das Buch ohne Probleme zu verstehen.

Literaturempfehlungen

Logisch, oder? 🙂

*

Die perfekte Ergänzung für einen noch tieferen Einstieg in das Testen deiner Software:

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• JUnit
• Unit Testing with JUnit – Tutorial
• JUnit Cheat Sheet

Um Werkzeuge, die dem Entwickler beim Bauen seiner Software viel Arbeit abnehmen, geht es in der siebenundneunzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Die Episode ist wie meine Einführung in die Versionsverwaltung mit Git in mehrere Fragen aufgeteilt. Los geht es mit allgemeinen Fragen zu Build-Werkzeugen. Dann folgen Fragen zum Einsatz im eigenen Unternehmen. Und zuletzt gehen auf die Details von Gradle ein.

Allgemein

Die folgenden Fragen sind unabhängig vom konkreten Build-Werkzeug.

1. Was ist ein Build?
   • Der Vorgang, der alle Aktionen umfasst, die zum Erstellen einer lauffähigen und deploybaren Software aus Basisartefakten wie Sourcecode nötig sind.
2. Was macht ein Build-Werkzeug?
   • Mit einem Build-Werkzeug können alle notwendigen Build-Schritte automatisiert werden.
3. Was sind die Vorteile eines Build-Werkzeugs?
   • Die Software kann automatisiert und damit schneller und verlässlicher gebaut werden.
   • Kopfmonopole werden abgebaut.
   • „Works on my machine“ wird verhindert.
   • Ein automatischer Build ist die Grundlage für Continuous Integration/Delivery/Deployment.
4. Was ist ein Build-Script?
   • In einem Build-Script werden die notwendigen Build-Schritte definiert. Es wird vom Build-Werkzeug wie Programmcode ausgeführt.
5. Warum sollten Build-Scripts versioniert werden?
   • Letztlich sind die Build-Scripts ausführbarer „Code“, der ganz normal mit versioniert werden sollte. Allein, um Änderungen am Build mit Änderungen im Code zu synchronisieren und später auch noch frühere Builds nachstellen zu können.
6. Welche Aktionen kann ein Build-Werkzeug bei einem Build durchführen?
   • Abhängigkeiten auflösen (z.B. fremde JARs oder DLLs einbinden)
   • Kompilieren des Codes
   • Testen (mit Analyse der Code Coverage)
   • Statische Code-Analyse durchführen (z.B. Code-Style, bestimmte Bugs)
   • Paketieren der Anwendung (z.B. als JAR, DLL)
   • Snapshots der Software erzeugen und in ein Artefakt-Repository einstellen
   • Deployment der Anwendung auf ein Zielsystem
   • Maschinenunabhängig Projekte für die jeweilige IDE erstellen
   • Minification von Artefakten (z.B. CSS und JavaScript)
   • Obfuscation zum Schutz des Quellcodes
   • Technische Dokumentation der Software erzeugen
   • Alles, was man sonst noch so manuell tun müsste
7. Wie hängt das Build-Werkzeug mit Continuous Integration zusammen?
   • Ohne automatischen Build ist kein CI möglich!
8. Welche bekannten Build-Werkzeuge gibt es für Java, .NET, Ruby und C?
   • Java: Ant, Maven, Gradle
   • .NET: MSBuild
   • Ruby: Rake
   • C: make

Dein Unternehmen

Diese Fragen solltest du dir stellen, wenn du in deinem Unternehmen mit einem Build-Werkzeug arbeiten willst/musst.

1. Welche konkreten Build-Werkzeuge setzt dein Unternehmen ein?
2. Was musst du tun, um dieser auf deiner Maschine nutzen zu können?
3. Welche Konventionen musst du ggfs. einhalten, um sie in deinem Projekt nutzen zu können?
   • z.B. Ordnerstruktur des Projekts, Benennung der Komponenten.
4. Wo findest du Vorlagen für eigene Build-Scripts?
5. Welche Dateien gehören zum Build-Script deines Unternehmens und was sind ihre jeweiligen Aufgaben?
6. Welche Ordner und Dateien deines Projekts solltest du von der Versionierung ausschließen?

Gradle

Zum Schluss kommen noch ein paar einleitende Fragen zum konkreten Werkzeug Gradle.

1. Was ist Gradle?
   • Ein Build-Werkzeug für Java, das inzwischen z.B. der Standard für Android-Projekte ist.
2. Was sind die Vorteile von Gradle gegenüber Maven und Ant?
   • Gradle verwendet eine flexible und mächtige DSL für die Build-Scripts und kann sowohl deklarativ, als auch imperativ verwendet werden.
3. Was ist der Gradle Wrapper?
   • Eine Möglichkeit, um Gradle in der passenden Version für das aktuelle Build-Script automatisch herunterzuladen und damit den Build durchzuführen.
4. Mit welchem Befehl startest du einen normalen Build mit Gradle?
   • gradle build
5. Mit welchem Befehl räumst du dein Projektverzeichnis mit Gradle auf?
   • gradle clean
6. Mit welchem Befehl erzeugst du ein importierbares Eclipse-Projekt mit Gradle?
   • gradle eclipse

Literaturempfehlungen

Wenn du tiefer in Gradle einsteigen möchtest (was natürlich nur sinnvoll ist, wenn du es selbst einsetzt), empfehle ich dir dieses Buch von Joachim Baumann. Es hat uns beim Erstellen einer Vorlage für unsere eigenen Build-Scripts sehr geholfen.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Erstellungsprozess – Wikipedia
• Java Quickstart – Gradle User Guide Version 3.4.1
• The Gradle build system- Tutorial

Um Kapitel 10 (Konzepte der Programmierung) des Handbuchs für Fachinformatiker geht es in der sechsundneunzigsten Episode des Anwendungsentwickler-Podcasts.

Das Kapitel 10 des IT-Handbuchs für Fachinformatiker* von Sascha Kersken liefert einen Überblick über zentrale Konzepte der Programmierung: Algorithmen, Datenstrukturen, reguläre Ausdrücke, Netzwerkprogrammierung usw. Insgesamt ein spannendes Kapitel gefüllt mit viel Know-How für die Praxis. Auch wenn nicht so viel prüfungsrelevantes Wissen enthalten ist, sollte jeder Anwendungsentwickler die beschriebenen Inhalte kennen, da man ihnen früher oder später sehr wahrscheinlich bei der eigenen Arbeit begegnen wird.

• 10.1 Algorithmen und Datenstrukturen
  • Sortieralgorithmen zeigen gut die Unterschiede bei der Komplexität verschiedener Lösungen für das gleiche Problem (BubbleSort vs. QuickSort).
  • In einer der letzten Prüfungen war ein kleiner Sortieralgorithmus enthalten.
  • Der kleine Ausflug zur Rekursion und Iteration ist wichtig.
  • Suchalgorithmen sind für die Praxis nicht ganz so wichtig, bilden aber die Grundlage von Datenbanken. Daher begegnen sie uns – wenn vielleicht auch unbewusst – jeden Tag.
  • Die abstrakten Datenstrukturen Stack, Queue und Baum sind absolutes Grundwissen für jeden Entwickler. Es gibt keine Ausrede dafür, sie nicht zu kennen! Ich lasse sie in meinem Java-Tutorial auch immer einmal selbst programmieren.
• 10.2 Reguläre Ausdrücke
  • Ich bin immer wieder erstaunt, wie selten fertige Anwendungsentwickler sich mit regulären Ausdrücken auskennen. Ich könnte ohne sie nicht leben 🙂
  • Es gab schon einmal eine Aufgabe zu Textmustern in der IHK-Prüfung, die allerdings eine eigene Syntax vorgab. Aber die Idee der regulären Ausdrücke ist daher wohl als prüfungsrelevant einzustufen.
• 10.3 Systemnahe Programmierung
  • Prozesse und Pipes sind wichtige Konzepte für die systemnahe Programmierung, sie jeder Entwickler einmal gehört haben sollte. In der Praxis werden sie aber wohl nur relevant, wenn man halt systemnah programmiert 🙂
  • Threads sind ein Konzept, das heutzutage immer wichtiger wird. Da Prozessoren nicht mehr (oder kaum noch) vertikal skalieren, sondern horizontal, sollte jeder Entwickler sich mit der nebenläufigen Programmierung auseinandersetzen.
  • Viele moderne Sprachen bieten Abstraktionen für die nebenläufige Programmierung an, sodass man nicht selbst mit Threads hantieren muss.
• 10.4 Einführung in die Netzwerkprogrammierung
  • Jeder Entwickler sollte wissen, was eine Socket ist.
  • In der Praxis wird man aber wahrscheinlich wenig damit arbeiten, da einem moderne Sprachen das Low-Level-Coding abnehmen.
• 10.6 GUI- und Grafikprogrammierung
  • Ein netter Ausblick auf die eigene Programmierung von grafischen Ausgaben, aber für die Praxis und die Prüfung eher uninteressant, da man heutzutage sehr wahrscheinlich Frameworks dafür nutzen würde.
  • Das Unterkapitel zur fensterbasierten Programmierung und dem Event Handling ist allerdings wieder sehr praxisrelevant.
  • Auch in der mündlichen Prüfung haben wir schon öfter nach Events und Event Handlern gefragt.

Frühere Inhalte

• 10.5 Verteilte Anwendungen mit Java Enterprise Edition
  • Zurecht entfernt, da schwergewichtige Konzepte wie EJBs und SOAP heute eher eine untergeordnete Rolle spielen und in der Kürze ohnehin nicht vermittelt werden könnten.

Literaturempfehlungen

Was sonst? 🙂

http://fiae.link/HandbuchFachinformatiker*
(direkt beim Rheinwerk-Verlag bestellen*)

Die erwähnten Bücher zum Buchclub und zur Einarbeitung in Java EE gibt es hier:

• Jeff Langr – Pragmatic Unit Testing in Java 8 with JUnit (Affiliate)*
• Alexander Salvanos – Professionell entwickeln mit Java EE 7: Das umfassende Handbuch (Affiliate)*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Regex Crossword

Nachdem letzte Woche bereits häufige Fragen im Fachgespräch rund um das Thema Softwaretests besprochen wurden, folgen nun einige Detailfragen zum Bereich Unit-Tests in der fünfundneunzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Was ist eine Unit?
  • Die kleinste zu testende Einheit, meist eine Methode.
• Wie unterscheiden sich Unit- bzw. Komponenten-, Integrations- und Systemtest?
  • Unit-Test: Einzelne Komponente wird in Isolation getestet
  • Integrationstest: Das Zusammenspiel mehrerer Komponenten wird getestet
  • Systemtest: Das System als Ganzes wird auf Funktionalität getestet
• Was ist ein Unit-Test-Framework?
  • Ein Softwareframework, das den Entwickler beim Schreiben automatischer Tests unterstützt.
• Was ist eine Assertion?
  • Eine konkrete Prüfung in einem Unit-Test (z.B. Gleichheit von Werten).
• Was bedeutet AAA?
  • Arrange, Act, Assert
• Was ist Mocking?
  • Abhängigkeiten werden durch Fake-Objekte ersetzt, um die eigentlich zu testende Komponente in Isolation ausführen zu können.
• Was ist Code-Coverage?
  • Der Grad der Abdeckung des Codes durch die Tests.
• Welche Eigenschaften sollten Unit-Tests haben?
  • Schnell, einfach, isoliert, wiederholbar, verlässlich, keine Infrastruktur verwenden.
• Was ist ein Mutationstest?
  • Ein Test, der den zu testenden Code verändert, um die Testabdeckung durch vorhandene Tests zu prüfen.
• Was ist die Testpyramide?
  • Eine Empfehlung für das Verhältnis zwischen Unit- (viele), Integrations- (mehrere) und Systemtests (wenige).
• Wie kann man Oberflächen testen?
  • Manuell oder mit Hilfe von Frameworks wie Selenium.

Literaturempfehlungen

Einen sehr schönen Einstieg in das Thema Unit-Testing liefert Jeff Langr in seinem Buch Pragmatic Unit Testing in Java 8 with JUnit*. Er fängt „bei 0“ an und erklärt alle wichtigen Konzepte inkl. Mocking für die Praxis. Außerdem arbeitet er auch mit den neuen Features von Java 8 (Lambdas, Streams) um die Tests zu optimieren. Sehr empfehlenswert! Ich lasse es meine Azubis als Grundlagenbuch lesen und werde bald auch einen Buchclub dazu aufnehmen.

*

Und wenn du ein Buch lesen möchtest, dass dir noch einmal einen völlig anderen Blick auf das Vorgehen bzgl. der Tests beim Schreiben einer Software ermöglicht, empfehle ich dir wärmstens Growing Object-Oriented Software, Guided by Tests*. Die beiden Autoren zeigen ein komplett testgetriebenes Vorgehen, das mit Integrationstests beginnt. Ein sehr spannender Ansatz, der mit einem großen Praxisbeispiel in Java illustiert wird. Hier habe ich das Buch schon vor einigen Jahren rezensiert: Growing Object-Oriented Software, Guided by Tests (Freeman/Pryce).

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Testabdeckung – Wikipedia
• Regressionstest – Wikipedia

Einige häufige Fragen im Fachgespräch rund um das Thema Softwaretest sind Inhalt der vierundneunzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Wie lassen sich Testverfahren klassifizieren?
  • Was wird getestet?
    • Komponente, Integration mehrerer Komponenten oder das ganze System.
    • Funktionale oder nicht-funktionale Anforderungen.
  • Wie werden sie durchgeführt?
    • Durch den Menschen (manuell) oder eine Maschine (automatisch).
  • Wer führt sie durch?
    • Entwickler oder Fachbereich.
  • Welche Kenntnisse sind für die Erzeugung von Testfällen nötig?
    • Nur das nach außen sichtbare Verhalten (Black-Box) oder auch der Sourcecode (White-Box).
  • Wann werden die Tests erstellt?
    • Test first vs. test last.
    • Alpha-/Beta-Test.
  • Wird die Software für den Test ausgeführt (dynamisch) oder nicht (statisch)?
  • Welches Ziel verfolgen die Tests?
    • Z.B. Regression verhindern, Last simulieren.
• Was ist der Unterschied zwischen Black- und White-Box-Test?
  • Bei Black-Box-Tests kennt der Tester nicht die interne Struktur der Software, sondern sieht nur das nach außen sichtbare Verhalten. Beim White-Box-Test wird der Sourcecode mit einbezogen, um z.B. bestimmte Testfälle zu definieren.
• Was sind Anweisungs-, Zweig- und Pfadüberdeckung?
  • Alle sind Maße für die Testabdeckung des Codes.
  • Bei der Anweisungsüberdeckung (C0) wird jede Anweisung im Code mind. einmal durchlaufen.
  • Bei der Zweigüberdeckung (C1) wird jeder Zweig im Code mind. einmal durchlaufen. Das heißt, bei if-Anweisungen wird sowohl der if-Zweig als auch der else-Zweig durch einen Test abgedeckt. Sie inkludiert die Anweisungsüberdeckung.
  • Bei der Pfadüberdeckung (C2) werden alle Pfade durch den Code getestet. Das heißt, dass z.B. alle möglichen Wege durch Schleifen abgedeckt sein müssen. Sie inkludiert die Zweigüberdeckung.
• Was ist die zyklomatische Komplexität?
  • Ein Maß für die Anzahl der möglichen Pfade durch den Code.
• Welche sonstigen Testverfahren gibt es noch?
  • Abnahmetest oder Akzeptanztest (User Acceptance Test): Finaler Test des Kunden, der das Projekt offiziell beendet.
  • Lasttest: Das System wird unter hohe Last gesetzt, um z.B. den gleichzeitigen Zugriff vieler Benutzer zu simulieren.
  • Smoketest: Erster grober Test der Software, um entscheiden zu können, ob weitere detaillierte Tests überhaupt sinnvoll sind.
  • Exploratives Testen: einfaches „Ausprobieren“ durch erfahrene Benutzer.

Literaturempfehlungen

Wenn du dich wirklich intensiv mit Softwaretests auseinandersetzen willst (oder musst) und auch etwas akademischer werden möchtest, gibt es eigentlich nur eine Empfehlung: Software-Qualität: Testen, Analysieren und Verifizieren von Software* von Peter Liggesmeyer. Das Buch hat mich persönlich bei meiner eigenen Masterarbeit zum Thema Test-Driven-Development begleitet und liefert knackige Definitionen für alle möglichen Begriffe aus dem Umfeld der Softwaretests. Es geht aber auch weit über das Testen hinaus und erklärt z.B. auch statische Codeanalyse und Code-Review-Verfahren.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts

Links

• Smoke testing – Wikipedia
• Softwaretest – Wikipedia
• Kontrollflussorientierte Testverfahren – Wikipedia
• McCabe-Metrik – Wikipedia
• Testabdeckung – Wikipedia

Um Kapitel 9 (Grundlagen der Programmierung) des Handbuchs für Fachinformatiker geht es in der dreiundneunzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt Kapitel 9 (Grundlagen der Programmierung)

Das Kapitel 9 des IT-Handbuchs für Fachinformatiker* von Sascha Kersken liefert einen kurzen Einstieg in mehrere unterschiedliche Programmiersprachen. Für einen tiefen Einstieg reicht das natürlich nicht aus, aber man bekommt einen guten Überblick über die Eigenschaften und Unterschiede der einzelnen Programmiersprachen. Als „Lernkapitel“ bietet es sich jedoch nicht an, da viele konkrete Syntaxelemente vorgestellt werden, die für die Praxis absolut relevant sind, aber in der Prüfung so detailliert wohl eher nicht abgefragt werden.

• 9.1 Die Programmiersprache C
  • Wichtige Programmiersprache! Allerdings (meiner Erfahrung nach) wenig bei IHK-Prüfungen eingesetzt.
  • Die Konzepte der prozeduralen Programmierung finden in den IHK-Aufgaben Anwendung.
  • Gute Erklärung grundlegender Begriffe wie Deklaration, Wertzuweisung und Kontrollstruktur.
  • Kurze Einführung in grundlegende Datentypen wie int, char und double.
  • Einige konkrete Tipps wie z.B. die Empfehlung, bei if immer geschweifte Klammern zu setzen.
  • Schöne Erklärung von Call by value und Call by reference mit Pointern.
  • Die Standardbibliothek ist nicht prüfungsrelevant.
• 9.2 Java
  • Guter Einstieg mit Liste der Unterschiede zu C.
  • Kurze Einführung in die Objektorientierung mit Überladen, Vererbung und Interfaces. Gut für einen ersten Überblick, aber für Details zu oberflächlich.
  • Abschluss mit kurzer Einführung in Collections und Enums. Wichtig für die Praxis.
• 9.3 Python (früher 9.3 Perl und 9.4 Ruby)
  • Python ist als bekannter Vertreter der dynamischen (Script-)Sprachen sehr interessant. Die Unterschiede zu statischen Sprachen sollte jeder Prüfling kennen.
  • Auch die Bedeutung von Whitespace in der Sprache ist spannend, da sie sauber formatierten Code erzwingt.
  • Im Gegensatz zu Java wird Snake Case für Bezeichner verwendet.
  • Intensive Behandlung von Listen und den dazu passenden „coolen“ Sprachfeatures.
  • Eine REPL bieten heute auch immer mehr Sprachen an. Sogar Java bekommt bald eine 🙂
  • Lambda-Funktionen sollte heute auch jeder Anwendungsentwickler kennen. Sie sind in fast allen modernen Programmiersprachen enthalten und bilden ein wichtiges Fundament der funktionalen Programmierung.
  • Die Standardbibliothek ist analog zu C eher uninteressant (für die Prüfung).
• 9.5 Zusammenfassung

Literaturempfehlungen

Was sonst? 🙂

http://fiae.link/HandbuchFachinformatiker*
(direkt beim Rheinwerk-Verlag bestellen*)

Und für einen richtigen Einstieg in eine der genannten Sprachen – natürlich Java 😉 – empfehle ich wie immer die „Insel*“!

http://fiae.link/JavaInsel*
(direkt beim Rheinwerk-Verlag bestellen*)

Wenn du einen wirklich tollen Überblick über einige der interessantesten Programmiersprachen inkl. ihrer konkreten Stärken haben möchtest, kann ich dir Seven Languages in Seven Weeks von Bruce Tate empfehlen, das ich in meinem privaten Blog schon einmal rezensiert habe.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Anwendungsentwickler-Podcast #12: Häufige Fragen im Fachgespräch – Programmierung (Teil 1)
• Anwendungsentwickler-Podcast #13: Häufige Fragen im Fachgespräch – Programmierung (Teil 2)