Explore every episode of the podcast IT-Berufe-Podcast
Dive into the complete episode list for IT-Berufe-Podcast. Each episode is cataloged with detailed descriptions, making it easy to find and explore specific topics. Keep track of all episodes from your favorite podcast and never miss a moment of insightful content.
Rows per page:
50
1–50 of 223
Title
Pub. Date
Duration
Lastenheft und Pflichtenheft – IT-Berufe-Podcast #189
12 Aug 2024
00:41:46
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)
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):
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.]
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.
Teamarbeit bei der Softwareentwicklung mit Christian Kranert – IT-Berufe-Podcast #188
06 May 2024
01:02:39
Um Teamarbeit bei der Softwareentwicklung geht es im Interview mit Christian Kranert in der einhundertachtundachzigsten Episode des IT-Berufe-Podcasts.
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
Aufbau und Ablauf der IHK-Abschlussprüfung in den IT-Berufen – IT-Berufe-Podcast #180
24 Oct 2022
00:51:16
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
Kaufmann/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:
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.
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…
die Arbeitsergebnisse adressatengerecht zu präsentieren und
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
Kaufmann/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 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.
Arrays und Listen (Lernzielkontrolle) – Anwendungsentwickler-Podcast #99
10 Apr 2017
00:41:44
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*.
Pragmatic Unit Testing in Java 8 with JUnit (Buchclub) – Anwendungsentwickler-Podcast #98
27 Mar 2017
00:34:50
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.
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.
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:
Einführung in Build-Werkzeuge – Anwendungsentwickler-Podcast #97
20 Mar 2017
00:43:21
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.
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.
Was macht ein Build-Werkzeug?
Mit einem Build-Werkzeug können alle notwendigen Build-Schritte automatisiert werden.
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.
Was ist ein Build-Script?
In einem Build-Script werden die notwendigen Build-Schritte definiert. Es wird vom Build-Werkzeug wie Programmcode ausgeführt.
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.
Welche Aktionen kann ein Build-Werkzeug bei einem Build durchführen?
Abhängigkeiten auflösen (z.B. fremde JARs oder DLLs einbinden)
Diese Fragen solltest du dir stellen, wenn du in deinem Unternehmen mit einem Build-Werkzeug arbeiten willst/musst.
Welche konkreten Build-Werkzeuge setzt dein Unternehmen ein?
Was musst du tun, um dieser auf deiner Maschine nutzen zu können?
Welche Konventionen musst du ggfs. einhalten, um sie in deinem Projekt nutzen zu können?
z.B. Ordnerstruktur des Projekts, Benennung der Komponenten.
Wo findest du Vorlagen für eigene Build-Scripts?
Welche Dateien gehören zum Build-Script deines Unternehmens und was sind ihre jeweiligen Aufgaben?
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.
Was ist Gradle?
Ein Build-Werkzeug für Java, das inzwischen z.B. der Standard für Android-Projekte ist.
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.
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.
Mit welchem Befehl startest du einen normalen Build mit Gradle?
gradle build
Mit welchem Befehl räumst du dein Projektverzeichnis mit Gradle auf?
gradle clean
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.
Buchclub: Handbuch für Fachinformatiker (Teil 13: Konzepte der Programmierung) – Anwendungsentwickler-Podcast #96
13 Mar 2017
00:37:06
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.
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.
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.
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.
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.
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.
Unit-Tests – Häufige Fragen im Fachgespräch – Anwendungsentwickler-Podcast #95
06 Mar 2017
00:38:16
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).
Testverfahren für Software – Häufige Fragen im Fachgespräch – Anwendungsentwickler-Podcast #94
27 Feb 2017
00:38:38
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.
Buchclub: Handbuch für Fachinformatiker (Teil 12: Grundlagen der Programmierung) – Anwendungsentwickler-Podcast #93
20 Feb 2017
00:29:12
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.
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.
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).
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.
Einführung in Continuous Integration – Anwendungsentwickler-Podcast #92
13 Feb 2017
00:42:53
Eine Einführung in die kontinuierliche Integration – Continuous Integration – gibt es in der zweiundneunzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Voraussetzungen
Völlig unabhängig von Programmiersprache oder Plattform.
Theoretisch auch ohne separate Software umsetzbar, aber einfacher mit etablierten Lösungen wie Jenkins, Team Foundation Server, Travis CI, Teamcity oder CruiseControl.
Alle Artefakte (Code, Oberflächen, Konfiguration usw.) müssen in der Versionsverwaltung liegen.
Ein automatischer Build des Projekts muss möglich sein (z.B. mit Gradle oder MS Build).
Der Build sollte möglichst schnell sein.
Die Funktionalität sollte mit automatischen Tests abgedeckt sein.
Entwickler müssen häufig – mindestens täglich – committen.
Vorteile
Das Projekt ist jederzeit auf dem neusten Stand automatisiert baubar.
Vermeidung von „Works on my Machine“.
Vermeidung langer Integrationsphasen vor Deployments.
Erziehung der Entwickler zu kleinen Commits, sauberem Code und automatisierten Tests.
Projektbeteiligte bekommen jederzeit kurzfristiges Feedback zum Projektstand.
Statische Codeanalyse ist möglich.
Einhaltung von Code-Konventionen, z.B. mit Checkstyle.
Wenn du nur einen einzigen Texteditor beherrschen dürftest, sollte es Vim sein 🙂 Mit Drew Neils Buch wirst du zum Profi bei der Bedienung des besten Editors der Welt.
*
Und wie schon in allen Linux-Episoden ist die „Linux-Bibel“ von Michael Kofler* mein Literaturtipp zur Vertiefung deiner Linux-Kenntnisse.
Idee: Mehrere Festplatten zu einem Verbund („array“) zusammenschließen
Ziel: Ausfallsicherheit und höhere Verfügbarkeit (durch Einführung von Redundanz)
Bei Ausfall einer Festplatte kann sie getauscht und das RAID-Array wiederhergestellt werden („Rebuild“), in dieser Phase ist das RAID durch die hohe Belastung aber anfälliger für einen weiteren Festplattenausfall.
keine Redundanz, Merksatz: „0 Redundanz“, „0 Sicherheit“
mindestens 2 Festplatten nötig
teilt Festplatten in gleich große Blöcke auf und verteilt die Daten darauf (stripes)
Kapazität kann komplett genutzt werden
dadurch kann schneller gelesen werden, da von mehreren Festplatten parallel gelesen wird
auch das Schreiben geht schneller, da Daten parallel auf mehrere Festplatten geschrieben werden (aufgeteilt)
fällt eine Festplatte aus, ist der gesamte Verbund defekt
Ausfallwahrscheinlichkeit steigt, da Einzelwahrscheinlichkeiten multipliziert werden (z.B. bei 1% Ausfallwahrscheinlichkeit 2,97% gesamt)
Einsatz: Streaming (viel Lesen, wenig Schreiben, Datenverlust verkraftbar bzw. anderweitig abgesichert), mehrere kleine zu einem großen Datenträger zusammenbauen
Nachteil: hohe Ausfallwahrscheinlichkeit
RAID 1: Mirroring
komplette Redundanz, Merksatz: „1-zu-1-Kopie“
mindestens 2 Festplatten nötig
Daten werden auf allen Festplatten identisch abgelegt
Kapazität wird halbiert oder gedrittelt usw.
Lesegeschwindigkeit kann erhöht werden, indem Daten parallel von mehreren Festplatten gelesen werden
Schreiben dauert länger, weil Daten auf mehrere Platten geschrieben werden müssen (Redundanz)
Verbund fällt erst aus, wenn alle Festplatten ausfallen
Ausfallwahrscheinlichkeit sinkt deutlich, z.B. bei 1% je Platte auf 0,0001%
auch Mirroring ist keine Datensicherung, Viren werden sofort auf alle Platten geschrieben
Einsatz: Hochverfügbarkeitssysteme
Nachteil: geringe Nettokapazität
RAID 5: Paritäten
Teilredundanz durch Ablage von Paritätsinformationen
mindestens 3 Festplatten nötig
zusätzlich zu den auf mehrere Festplatten verteilten Daten werden auf allen Festplatten Paritätsinformationen (z.B. XOR) je Datenblock abgelegt
Kapazität wird reduziert (z.B. 2/3 bei drei Festplatten)
Lesegeschwindigkeit kann erhöht werden, indem Daten parallel von mehreren Festplatten gelesen werden
Schreiben dauert durch Berechnung der Parität länger
Verbund fällt erst aus, wenn zwei Festplatten defekt sind
Ausfallwahrscheinlichkeit sinkt, z.B. bei 1% je Platte auf 0,0298%
Nachteil: bei häufigen Schreibzugriffen durch Berechnung der Parität langsamer
Irrelevante RAID-Level
RAID 2: Striping mit Fehlerkorrektur, nur bei Großrechnern eingesetzt
RAID 3/4: wie RAID 5 nur mit dedizierter Paritätsfestplatte (die dadurch stark belastet und zum Flaschenhals wird), bei RAID 3 wird auf Byte-Ebene und bei RAID 4 auf Block-Ebene gestript
RAID 6: wie 5 nur mit doppelter Parität
Kombinationen von RAID-Levels
best of both worlds aus anderen RAID-Leveln
immer von links nach rechts lesen und im Diagramm von unten nach oben: 01 -> zuerst werden zwei RAID 0 erstellt und dann zu einem RAID 1 zusammengebaut
ein Leg ist das RAID-Array „unten“ im Bild, aus dem das übergeordnete zusammengesetzt wird
es werden mind. 4 Festplatten benötigt
Kapazität wird halbiert
Verbund verträgt zwei Festplattenausfälle, aber es ist wichtig, welche Platten ausfallen
RAID 01
zwei Festplatten im gleichen Leg dürfen ausfallen
es kann nicht erkannt werden, welche Festplatte im RAID 0 ausgefallen ist, da dann das gesamte Array defekt ist
bei Ausfall einer Festplatte muss das gesamte Stripeset des Legs neu aufgebaut werden
RAID 10
zwei Festplatten in unterschiedlichen Legs dürfen ausfallen
bei Ausfall weniger Aufwand für Rebuild, weil nur im Leg gemirrort werden muss
Der eigene Webserver (Teil 2: Absicherung von SSH) – Anwendungsentwickler-Podcast #89
23 Jan 2017
00:37:24
Die Absicherung des eigenen Linux-Servers – im Speziellen des SSH-Zugangs – ist das Thema der neunundachzigsten Episode des Anwendungsentwickler-Podcasts.
Der eigene Webserver (Teil 1) – Anwendungsentwickler-Podcast #88
16 Jan 2017
00:44:13
Warum es schon für Auszubildende sinnvoll ist, einen eigenen (Web-)Server zu betreiben, erkläre ich in der achtundachzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Warum sollte ich mir überhaupt einen Server aufsetzen?
Besser kann man den professionellen Umgang mit Infrastruktur nicht lernen.
Keine Abhängigkeiten von Dienstanbietern.
Freiheit bei der Auswahl der Dienste.
Plattform für eigene Projekte.
Daten liegen in der eigenen Hoheit.
Weil es Spaß macht.
Weil es cool ist, eine eigene Domain (z.B. für E-Mail-Adressen) zu haben.
Ideen für moderne Projektpräsentationen – Anwendungsentwickler-Podcast #87
09 Jan 2017
00:43:22
Wie könnte eine moderne Abschlusspräsentation aussehen? Das diskutiere ich in der siebenundachzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Die guten alten Mythen der Projektpräsentation.
Fortschrittsbalken, Corporate Design und Seitenzahlen sollten in Zeiten von Presentation Zen* als überholt gelten und Relikte der Vergangenheit sein.
Die Mär von den „alteingesessenen“ Prüfern.
Es ist immer wieder spannend zu hören, wie viele „alte“ (und damit meine ich nicht das Alter, sondern die Einstellung) Prüfer es angeblich in den IT-Berufen gibt.
„Das haben wir schon immer so gemacht!“ Nur als Begründung für wichtige Entscheidungen im Projekt lassen wir das nicht gelten…
Prüfer sind auch nur Menschen (die unterhalten werden wollen).
Die Projektpräsentation ist kein Zirkus.
Es geht mir nicht darum, Witzigkeit und Oberflächlichkeit zu fordern.
Ich möchte die Inhalte des Projekts bestmöglich transportiert bekommen.
Der Stil muss zu dir passen.
Verstell dich nicht für die Projektpräsentation. Das bezieht sich allerdings auch auf die „alte“ Art zu präsentieren.
Du darfst dich auch einmal etwas trauen.
Wähle das beste Medium.
Es geht immer um den Inhalt! Die Folien sind nur Beiwerk.
Weder PowerPoint noch Prezi (noch Tool X) führen automatisch zu guten Präsentationen. Aber genauso wenig zu schlechten.
Halte formale Vorgaben deiner IHK ein.
Wenn du ein wenig recherchierst, wirst du wahrscheinlich feststellen, dass es nur wenige „harte“ Vorgaben gibt.
Frag deine Lehrer, wenn du keine Vorgaben findest.
Oder ignoriere alles und mach dein eigenes Ding!
Überrasche die Prüfer.
Wähle einen spannenden/ungewohnten Einstieg in die Präsentation.
Verzichte auf die üblichen Floskeln wie „Vielen Dank für die Aufmerksamkeit.“.
Setze gezielt Humor ein.
Aber bitte mit Bedacht und ein wenig Intelligenz.
Präsentiere visuell und nicht textuell.
Wenn du ein wenig nachdenkst und experimentierst, wirst du fast alle deine Inhalte visuell darstellen und auf Text fast vollständig verzichten können.
Gib deiner Präsentation eine persönliche Note.
Verwende eigene Bilder anstatt Stock-Fotos. Mit den Handys von heute ist das kein Problem mehr. Alternativ verwendest du eine vernünftige Kamera*.
Gestalte deine Agenda oder sogar alle Folien mit Bezug zu deinem Projekt.
Zeige ein Foto von dir selbst.
Baue sinnvolle Geschichten zum Projekt in deine Präsentation ein.
Literaturempfehlungen
Wie immer, wenn es um die Abschlusspräsentation geht, kann ich nur wärmstens die Lektüre von Presentation Zen* empfehlen. Niemand will mehr langweilige Textwüsten sehen!
Das ISO/OSI-Modell (Teil 3) – Anwendungsentwickler-Podcast #85
05 Dec 2016
00:33:14
Weiter geht es mit der Schicht 4, der Transportschicht, in Teil 3 meiner Reihe zum ISO/OSI-Modell in der fünfundachzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
4: Transportschicht (Transport Layer)
Wie kommen auch große Datenmengen vollständig und in der korrekten Reihenfolge beim richtigen Dienst des Empfängers an?
Das ISO/OSI-Modell (Teil 2) – Anwendungsentwickler-Podcast #84
28 Nov 2016
00:36:21
Die Schichten 2 und 3 (Sicherungs- und Vermittlungsschicht) des ISO/OSI-Modells sind das Thema der vierundachzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Auf den beiden Schichten arbeiten viele bekannte Hardwaregeräte und Protokolle, die auch für die Abschlussprüfung hochgradig relevant sind.
2: Sicherungsschicht (Data Link Layer)
Wie kommen die Daten sicher (vollständig und fehlerfrei) beim korrekten Empfänger (physikalische Zieladresse) an? Die Schicht ist unterteilt in MAC und LLC.
Das ISO/OSI-Modell (Teil 1) – Anwendungsentwickler-Podcast #83
21 Nov 2016
00:32:02
Eine allgemeine Einführung in das OSI-Referenzmodell und seine erste Schicht (Bitübertragungsschicht bzw. Physical Layer) sind das Thema der dreiundachzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Allgemeines
Das ISO-/OSI-Modell ist ein herstellerunabhängiges Referenzmodell in Form einer Schichtenarchitektur für Kommunikationssysteme.
Es beschreibt die Netzwerkkommunikation von der konkreten Bitübertragung z.B. über ein Glasfaserkabel bis hin zu den Anwendungen, die abstrakte Befehle austauschen.
Die Schichten stellen der jeweils darüber liegenden Schicht über definierte Schnittstellen ihre Dienste bereit.
Die Schichten 1 bis 4 sind die transportorientierten Schichten, 5 bis 7 die anwendungsorientierten Schichten.
1: Bitübertragungsschicht (Physical Layer)
Wie kommen die Daten physikalisch vom Sender zum Empfänger? Beispiele: Glasfaser, Kupferkabel, Funk.
Organisation einer eigenen Konferenz – Anwendungsentwickler-Podcast #82
14 Nov 2016
00:43:32
Die Organisation und Durchführung einer eigenen Konferenz ist das Thema der zweiundachzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Nachdem ich letzte Woche erzählt habe, wie wir unseren Softwareentwickler-Stammtisch ins Leben gerufen haben, geht es dieses Mal weiter mit der Organisation einer eigenen Konferenz.
Gehe immer davon aus, dass irgendetwas schief laufen wird (z.B. Ersatzbeamer mitnehmen).
Biete einen Early Bird für die Tickets an, um schnell das Interesse zu klären (und schlaflose Nächte zu vermeiden).
Sammle frühzeitig die Konferenzunterlagen (insb. Flyer) ein, um doppelte Arbeit zu vermeiden.
Hole das Feedback der Teilnehmer direkt am Ende der Konferenz ein.
Kläre vorab, wer (gute) Fotos der Konferenz macht.
Empfehlungen für Konferenzmaterial (Mappen und Badges)
Die Konferenzunterlagen (Agenda, Feedbackbogen, Flyer der Sponsoren) habe ich in diesen Dokumententaschen* im Format DIN A4 zusammengestellt. Sie machen trotz des geringen Preises einen stabilen Eindruck und es passten locker alle Unterlagen hinein.
Die habe ich dann in die passenden Ausweishüllen* gesteckt und an einem blauen Halsband* befestigt. Da Blau die Konferenzfarbe war, passte das sehr gut. Es gibt die Bänder aber natürlich noch in anderen Farben.
*
*
Literaturempfehlungen
Der Pluralsight-Kurs „Starting and Running a Successful User Group“, den ich bereits letzte Woche empfohlen habe, enthält auch ein separates Modul zum Thema Konferenzplanung. Daher kann ich ihn auch für dieses Thema wärmstens empfehlen. Ich selbst habe den Kurs gerade noch rechtzeitig vor der SEROM angeschaut und konnte dadurch noch ein paar kleine Fehler vermeiden.
Organisation einer eigenen User Group – Anwendungsentwickler-Podcast #81
07 Nov 2016
00:33:39
Die Organisation und Durchführung einer eigenen User Group ist das Thema der einundachzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Am vergangenen Freitag, den 04.11.2016 fand im Fizz in Vechta die erste Softwareentwicklungskonferenz SEROM statt. Das Motto der Veranstaltung war Softwareentwicklung im Mittelstand. Da ich die Organisation dieser Konferenz übernommen habe, erzähle ich in der aktuellen Podcast-Episode ein wenig über meine Erfahrungen. Diese Woche geht es los mit der Organisation einer User Group und beim nächsten Mal geht es dann um die Planung einer eigenen Konferenz.
Den Pluralsight-Kurs „Starting and Running a Successful User Group“ habe ich für mich persönlich leider etwas zu spät entdeckt. Ich habe ihn erst vor ein paar Wochen durchgearbeitet, aber der Stammtisch existiert ja bereits seit 2014. Wenn du noch ganz am Anfang stehst, wirst du sicherlich ein paar gute Tipps mitnehmen können.
Ablauf des Bewerbungsverfahrens für potentielle Azubis – Anwendungsentwickler-Podcast #80
17 Oct 2016
00:52:08
Der Ablauf des Bewerbungsverfahrens für Azubis zum Fachinformatiker Anwendungsentwicklung bzw. auf das duale Studium der Wirtschaftsinformatik ist das Thema der achzigsten Episode des Anwendungsentwickler-Podcasts.
Aus den eingegangenen schriftlichen Bewerbungen sortieren wir zunächst die vielversprechendsten Kandidaten aus. Dabei schauen wir nicht allein auf die Zeugnisnoten, sondern insb. auch darauf, ob ein Interesse am angestrebten Beruf vorhanden ist. Viel wichtiger als perfekte Noten sind daher zum Beispiel Praktika in anderen Unternehmen mit Bezug zur Softwareentwicklung.
Aber natürlich sind auch die Noten interessant für uns. Dabei schauen wir vor allem auf die Noten in den Fächern Mathe, Deutsch und Englisch. Englisch, da fast alle wichtigen und interessanten Texte zur Programmierung auf Englisch vorliegen. Mathe, weil meiner Meinung nach ein gewisser Bezug zwischen der logischen Denkweise der Mathematik und der Programmierung besteht. Und Deutsch, weil es bei der Softwareentwicklung nicht nur um das Erzeugen von Code geht, sondern auch um die schriftliche Kommunikation z.B. mit Kunden und natürlich auch die Dokumentation von Anwendungen.
Interessant sind für uns auch immer mehrere Zeugnisse, um einen Trend erkennen zu können. Außerdem gibt es z.B. in der Mathematik ganz unterschiedliche Themenbereiche (z.B. Kurvendiskussion und Stochastik), die dem Bewerber leichter oder schwerer fallen, und eine einzelne Note ist dann wenig aussagekräftig. Sehr gut ist es natürlich auch, wenn die Kandidaten Kurse in Informatik belegt haben. Aber nicht, weil wir Vorwissen erwarten, sondern weil das (wie bereits oben erwähnt) ein gewisses Interesse am Beruf zeigt.
Vorstellungsgespräche
Die interessantesten Kandidaten laden wir zu einem Vorstellungsgespräch zu uns ein. Üblicherweise sprechen wir ca. eine halbe Stunde mit den Bewerbern. Das gestaltet sich als ein eher lockeres Gespräch. Wir machen keine Leistungsabfragen oder fragen Fachbegriffe ab. Vielmehr muss deutlich werden, dass der Bewerber ins Team passt, und ein gewisses Engagement und Initiative mitbringt. Er sollte einfach glaubhaft vermitteln, dass der Beruf des Anwendungsentwicklers der richtige für ihn ist.
Ein paar allgemeine Informationen setzen wir beim Bewerber allerdings auch voraus. So macht es einen sehr schlechten Eindruck, wenn der Kandidat nicht mehr weiß, auf welchen Beruf er sich beworben hat (ist leider schon vorgekommen) oder in welchem Unternehmen er eigentlich gerade sitzt. Das Geschäftsfeld und ein wenig über die Historie des Unternehmens sollten dem Bewerber also durchaus bekannt sein. Das Internet bietet zahlreiche Möglichkeiten, um sich darüber umfassend zu informieren.
Aber auch der potentielle Azubi soll natürlich über das Unternehmen informiert werden. So sind z.B. die Arbeitszeiten, die Ausbildungsvergütung und die Sozialleistungen sowie das Betriebsumfeld Themen des Gesprächs.
Einstellungstest
Nach dem Vorstellungsgespräch absolvieren die Bewerber dann einen ca. anderthalbstündigen schriftlichen Einstellungstest. Dabei geht es vor allem um die Bereiche Mathematik und Englisch, die jeder Bewerber aus der Schule kennen sollte. Außerdem werden auch ein paar allgemeine Fragen aus der IT gestellt, die auf ein allgemeines Interesse am Beruf schließen lassen, z.B. was HTTP ist oder welche Betriebssysteme es so gibt.
Einen separaten Bereich zum Thema Programmierung gibt es auch. Wir erwarten allerdings auf keinen Fall, dass unsere Bewerber schon programmieren können. Dennoch bieten viele Schulen inzwischen Programmierkurse an. Und falls Vorwissen vorhanden ist, gibt uns der Test einen kleinen Aufschluss über die vorhandenen Erfahrungen. Konkrete Programmieraufgaben gibt es allerdings nur sehr wenige. Vielmehr geht es um einfache logische Zusammenhänge, für die man nicht programmieren können muss.
Vorstellungstag
Die vielversprechendsten Kandidaten aus Vorstellungsgesprächen und Tests laden wir üblicherweise für einen halben Tag noch einmal zu uns ein. An diesem Nachmittag gehen wir z.B. einmal durch unser Bürogebäude, schauen uns den Serverraum an und besuchen die Kollegen aus der Abteilung, damit die Bewerber sich ein besseres Bild ihres zukünftigen Arbeitsplatzes machen können. Außerdem gehen wir den Einstellungstest des Kandidaten durch und geben ein Feedback zu den Ergebnissen.
Aber auch wir wollen natürlich einen guten Eindruck des Kandidaten bekommen, daher ist der Großteil des Tages für ein gemeinsames Programmieren reserviert. Dabei lösen wir zusammen kleine Programmieraufgaben, die ich so auch in den ersten Wochen der Ausbildung mit den zukünftigen Azubis bearbeiten würde. Auch hier geht es wieder einmal nicht darum, schon programmieren zu können, sondern darum, herauszufinden, ob zwischenmenschlich eine Zusammenarbeit zwischen Azubi und Ausbilder denkbar wäre, und ob ein gewisses Verständnis für die Programmierung vorhanden ist.
Außerdem bietet der Vorstellungstag die Gelegenheit, noch offene Fragen beider Seiten zu klären. Das beinhaltet bei uns auch ein Gespräch „unter vier Augen“ mit den aktuellen Azubis des Unternehmens, die bestimmte Fragen sicherlich besser beantworten können, als der böse Ausbilder 😉 Am Ende dieses Tages sollen das Ausbildungsunternehmen und der potentielle Azubi ein gutes Bild von der zukünftigen Zusammenarbeit haben, sodass sowohl wir als auch der Bewerber diese wichtige Entscheidung für die nächsten drei Jahre treffen kann.
Tipps zur Vorbereitung auf das Bewerbungsverfahren
Informationen zum Berufsbild einholen (z.B. übliche Aufgaben, Tagesablauf).
Informationen zur Ausbildung einholen (z.B. Ort der Berufsschule, Dauer).
Argumentation für die eigene Berufswahl zurechtlegen (warum möchtest du Anwendungsentwickler werden?).
Informationen zum Unternehmen einholen (z.B. Geschäftsfeld, Größe, Historie).
Eigene Fragen an das Unternehmen vorbereiten (z.B. Vergütung, Ablauf der Ausbildung, Inhalte der Ausbildung).
Eigene Bewerbung mitnehmen (z.B. bei Fragen zu Zeugnisnoten oder Inhalten des Anschreibens).
Pünktlich erscheinen, aber auch nicht überpünktlich (10-15 Minuten vorher da sein reicht aus).
Ggfs. aktuelles Tagesgeschehen für Smalltalk verfolgen (z.B. Nachrichten).
Grundsätzlich: offen und ehrlich sein, nicht verstellen.
Um das beliebte Prüfungsthema Datensicherung geht es in der einhundertachtundsiebzigsten Episode des IT-Berufe-Podcasts.
Inhalt
Datensicherung ist quasi das deutsche Wort für Backup und behandelt das Sichern und Wiederherstellen von Daten auf Sicherungsmedien wie Magnetbändern, externen Festplatten oder der Cloud. Es geht hierbei um den Schutz vor Datenverlust.
Die Datensicherung ist ein Teil der Datensicherheit, der sich um das Schutzziel Verfügbarkeit kümmert.
Warum können Daten verloren gehen?
Hardwaredefekte, Probleme im Stromnetz, Feuer/Wasser, Naturkatastrophen, menschliches Versagen oder Vorsatz (z.B. absichtliches Löschen oder Diebstahl), Ransomware
Ein Datenverlust kann für Unternehmen (aber auch Privatpersonen) große negative Auswirkungen haben. In schlimmen Fällen kann das Unternehmen nicht weiter arbeiten und muss Insolvenz anmelden.
Mitarbeiter sollten zum Thema Datenverlust sensibilisiert werden.
Was sind die Konsequenzen eines Datenverlustes für das Unternehmen und die Person selbst?
Dateien sofort abspeichern und nicht erst nach stundenlanger Arbeit.
Dateien regelmäßig speichern.
Nicht nur auf der eigenen Festplatte speichern, sondern im Netzwerk.
Was sind sicherungswürdige Daten?
Daten, die man nicht ohne Weiteres wiederbeschaffen kann (z.B. selbst erstellte Dateien, Fotos, Dokumente, Arbeitsergebnisse).
Meist werden Betriebssystemdaten und Programminstallationen nicht gesichert.
Grundsätzlich kommt es darauf an, wie schnell Daten wiederhergestellt werden können müssen. Auch das Betriebssystem kann daher gesichert werden müssen, wenn eine Neuinstallation zu lange dauern würde.
Es gibt auch gesetzliche Aufbewahrungsfristen für Daten, aber bitte nicht mit Archivierung durcheinanderbringen.
Wichtig bei der Datensicherung: auch die Datenwiederherstellung testen!
Wie erkennt die Software, welche Daten zu sichern sind?
Metadaten wie letztes Änderungsdatum, Archiv-Flag oder Dateihash.
Wie viele Daten werden gesichert und wie lange dauert die Wiederherstellung?
Trade Off zwischen geringem Speicherverbrauch bzw. langer Backuplaufzeit und schneller Wiederherstellungsdauer.
Unterschiedliche Verfahren: Vollbackup (alle Daten sichern), differenzielles Backup (nur geänderte Daten zum letzten Vollbackup werden gesichert) und inkrementelles Backup (geänderte Daten zum letzten Voll- oder inkrementellen Backup werden gesichert).
Vollbackup: Viel Speicherverbrauch, lange Backuplaufzeit, schnelle Wiederherstellung (nur 1 Backup nötig).
Differenzielles Backup: Mittelweg zwischen Speicherverbrauch/Backuplaufzeit und Wiederherstellung (2 Backups nötig).
Schritt 3: externe Festplatte außerhalb des Hauses.
Bestimmte Daten zum schnellen/einheitlichen Zugriff verschlüsselt in der (eigenen) Cloud.
Produktempfehlungen
Ich verwende seit Jahren die externen Festplatten von Western Digital* für meine privaten (!) Backups. Sie sind relativ günstig und benötigen lediglich einen USB-Anschluss am PC. Sie sind sehr klein und kompakt und auch recht leicht.
*
Zusammen mit einer praktischen Trage- und Schutztasche* kann man sie gut für Außer-Haus-Sicherungen nutzen. Dafür solltest du die Daten dann aber verschlüsseln, z.B. mit Bitlocker.
*
Für die schnelle Ad-hoc-Datensicherung zwischendurch nutze ich – ebenfalls seit einigen Jahren – ein NAS von Synology*. Das hat neben der Datensicherungsfunktion auch noch einen Haufen anderer Funktionen, wie z.B. Streamingserver für Multimedia, Webserver und viele weitere.
*
Zum Kopieren der Dateien nutze ich keine spezielle Backup-Software, sondern das kostenfreie SyncToy von Microsoft.
Fehlerbehandlung (Lernzielkontrolle zu Exceptions) – Anwendungsentwickler-Podcast #79
10 Oct 2016
00:41:52
Eine Lernzielkontrolle zu Exceptions (in Java) gibt es in der neunundsiebzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Exceptions
Was ist eine „Exception“?
Eine unerwartete Ausnahmesituation in einem Programm, meistens ein Fehler.
Oder: Die Klasse, die dieses Konzept in der Programmiersprache repräsentiert.
Was ist die Analogie zur Erklärung der Behandlung von Exceptions?
Man „wirft“ und „fängt“ Exceptions wie einen Ball.
Wie kann man grundsätzlich mit Exceptions umgehen?
Man kann sie entweder direkt fangen (und das Problem lösen) oder dies an den Aufrufer delegieren (weiterwerfen).
Wie behandelt man eine Exception in Java?
Mittels try, catch und finally.
Wann braucht man einen finally-Block?
Wenn eine Operation unter allen Umständen nach try/catch ausgeführt werden muss (insb. wenn im catch-Block potentiell auch Fehler auftreten können).
Was ist try-with-resources?
Ein Sprachkonstrukt in Java, das dafür sorgt, dass Ressourcen nach ihrer Nutzung sauber wieder geschlossen werden, egal ob eine Exception auftritt oder nicht. Die Ressource muss dafür java.lang.AutoCloseable implementieren. Entspricht using in .NET.
Was macht das Schlüsselwort throw?
Wirft eine Exception.
Was macht das Schlüsselwort throws?
Markiert eine Methode als potentiell fehleranfällig und zwingt den Aufrufer zur Fehlerbehandlung.
Was ist der Unterschied zwischen „checked“ und „unchecked“ Exceptions?
Checked Exceptions (die es nur in Java gibt), müssen behandelt werden (der Compiler prüft das). Unchecked Exceptions (z.B. nicht vorhersehbare Laufzeitfehler wie „Speicher voll“) müssen nicht behandelt werden.
Wie erzeugt man seine eigenen Exceptions?
Man kann eigene Klassen von Exception erben lassen. Diese können dann auch „echte“ Attribute und Methoden beinhalten.
Was ist der „Call Stack“?
Der Aufrufstack enthält die Rücksprungadressen aller im bisherigen Programmablauf aufgerufenen Methoden. Darüber kann man nachvollziehen, wie das Programm zur aktuellen Position gelangt ist. Jede Exception hat den Call Stack bis zu ihrem Auftreten als Attribut.
Sollte man Exceptions zur Steuerung des Programmablaufs einsetzen?
Nein, da Exceptions – z.B. wegen des Call Stacks – recht „teuer“ sind.
Wie sieht die Hierarchie von Exceptions in Java grob aus?
Produktspezifika sind für die IHK-Prüfung irrelevant und veralten recht schnell in der Praxis. MySQL selbst ist eigentlich schon durch MariaDB abgelöst.
Eine (sehr) kurze Einführung in die Datenbankprogrammierung mit JDBC. Nett zu wissen, aber für die Praxis nicht ausreichend und für die Prüfung irrelevant.
Die Kurzeinführung in CouchDB auf einer Seite reicht auch bei Weitem nicht aus, um sich Wissen für die Prüfung anzueignen.
Buchclub: Handbuch für Fachinformatiker (Teil 10: Dateiformate und Sicherheit) – Anwendungsentwickler-Podcast #75
12 Sep 2016
00:26:18
Die beiden kurzen Kapitel 17 (Weitere Datei- und Datenformate) und 21 (Computer- und Netzwerksicherheit) sind Inhalt der fünfundsiebzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Kapitel 17 (Weitere Datei- und Datenformate)
Es geht weiter mit ebenso wichtigen Begriffen: Exploits, DoS, Rootkits, SQL-Injection, Firewalls, IDS.
Praxisbeispiel iptables ist interessant für den eigenen Server.
Die Einführung in die Kryptographie ist auch sehr praxis- und prüfungsrelevant. Gerade symmetrische und asymmetrische Verschlüsselung sollte jeder ITler kennen.
Buchclub: Handbuch für Fachinformatiker (Teil 9: XML) – Anwendungsentwickler-Podcast #73
29 Aug 2016
00:36:44
Das Kapitel 16 (XML) des IT-Handbuchs für Fachinformatiker* ist das Thema der dreiundsiebzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
XML ist – trotz der wachsenden Beliebtheit von JSON – immer noch eines der wichtigsten Austauschformate in der IT. Das entsprechende Kapitel des IT-Handbuchs für Fachinformatiker* enthält viele prüfungs- und praxisrelevante Inhalte.
Wohlgeformtheit: nur ein Wurzelelement, korrekte Schachtelung der Elemente, alle Elemente müssen geschlossen werden, nur erlaubte Elementnamen, Attributwerte immer in Anführungszeichen, Sonderzeichen durch Entitätsreferenzen ersetzen
Ich selbst habe vor mehreren Jahren mit einer älteren Auflage von Einstieg in XML* von Helmut Vonhoegen XML gelernt und es hat mir sehr gut gefallen. Das Buch ist umfangreich und gut verständlich geschrieben.
Bewertung von Auszubildenden (Teil 2) – Anwendungsentwickler-Podcast #72
22 Aug 2016
00:32:38
Die konkreten Punkte auf meinen Evaluierungsbögen für Auszubildende und Ausbilder sind das Thema der zweiundsiebzigsten Episode des Anwendungsentwickler-Podcasts.
Evaluierungsbögen
Meine Evaluierungsbögen kannst du hier in Form von PDF-Dateien herunterladen.
Wenn du sie als editierbare Word-Dateien* herunterladen möchtest, melde dich einfach für meinen Newsletter an. Dann bekommst du direkt den entsprechenden Download-Link.
Selbstevaluierung des Azubis
Evaluierung des Azubis
Evaluierung des Ausbilders
Literaturempfehlungen
Das Konzept der One-on-Ones habe ich aus dem Manager Tools Podcast, den ich bereits seit vielen Jahren verfolge. Kürzlich sind die zentralen Inhalte der Ansätze von Manager Tools auch als Buch The Effective Manager* erschienen, das ich sehr empfehlen kann. Es fasst auf ein paar hundert Seiten die wichtigsten Aussagen von über 10 Jahren Podcast zusammen.
Bewertung von Auszubildenden (Evaluierungsbögen) – Anwendungsentwickler-Podcast #71
15 Aug 2016
00:29:16
Die Evaluierung von Auszubildenden und Ausbildern ist Thema der einundsiebzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Ich führe wöchentlich halbstündige Gespräche (O3 = One-on-Ones) mit jeder/m Auszubildenden.
10 Minuten für die/den Azubi/ne, 10 Minuten für mich, 10 Minuten für die Zukunftsplanung.
In halbjährlichen Evaluierungsgesprächen gehen wir alle bisherigen Aufgaben des Azubis durch, besprechen Wünsche bzgl. zukünftiger Aufgaben, sprechen über evtl. vorhandene Lernschwierigkeiten und wie sie behoben werden können, Probleme mit Kollegen usw.
Auch die Bewertung des Ausbilders ist Bestandteil dieses Gesprächs, damit beide Seiten etwas lernen können.
Die Gespräche werden anhand eines Fragebogens mit offenen Fragen zur Ausbildung geführt, damit nichts vergessen wird und beide Seiten sich entsprechend vorbereiten können.
Im Anschluss schreibe ich dann ein kurzes Protokoll mit „ToDo-Listen“, die als Grundlage für das nächste Gespräch dienen.
Durch die wöchentlichen Gespräche ist allerdings auch meist schon Vieles geklärt, sodass in den halbjährlichen Terminen eher langfristige Themen wie Prüfungsvorbereitung, potentielle Aufgaben nach der Ausbildung usw. behandelt werden.
Evaluierungsbögen
Meine Evaluierungsbögen kannst du hier in Form von PDF-Dateien herunterladen.
Wenn du sie als editierbare Word-Dateien* herunterladen möchtest, melde dich einfach für meinen Newsletter an. Dann bekommst du direkt den entsprechenden Download-Link.
Selbstevaluierung des Azubis
Evaluierung des Azubis
Evaluierung des Ausbilders
Literaturempfehlungen
Das Konzept der One-on-Ones habe ich aus dem Manager Tools Podcast, den ich bereits seit vielen Jahren verfolge. Kürzlich sind die zentralen Inhalte der Ansätze von Manager Tools auch als Buch The Effective Manager* erschienen, das ich sehr empfehlen kann. Es fasst auf ein paar hundert Seiten die wichtigsten Aussagen von über 10 Jahren Podcast zusammen.
Buchclub: Handbuch für Fachinformatiker (Teil 8: JavaScript und AJAX) – Anwendungsentwickler-Podcast #70
08 Aug 2016
00:40:46
Das Kapitel 20 (JavaScript und Ajax) des IT-Handbuch für Fachinformatiker* ist das Thema der siebzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
AJAX sollte jeder Anwendungsentwickler für die Prüfung kennen. JavaScript ist zwar eine sehr wichtige Programmiersprache in der Praxis, wird in der Prüfung aber wohl eher keine große Rolle spielen. Falls dein Abschlussprojekt eine Webanwendung ist, wirst du aber definitiv nicht drumherum kommen.
Im Frontend gibt es keine Alternative zu JavaScript. Daher sollte jeder (Web-)Entwickler JavaScript kennen.
Spezielle programmiersprachenspezifische Fragen werden aber in der Prüfung eher nicht gestellt.
Die grundlegenden Eigenschaften von JavaScript sollten bekannt sein: dynamisch und schwach typisiert, objektorientiert (aber prototypbasiert und klassenlos) bzw. Multiparadigmensprache (prozedural, funktional, objektorientiert).
AJAX ist eine verbreitete Technologie heutzutage und jeder (Web-)Entwickler sollte sich auf Fragen dazu in der Prüfung – mindestens im Fachgespräch – einstellen.
jQuery
Für die Prüfung wohl uninteressant, aber für die Praxis unerlässlich.
Rückblick auf die Fachgespräche der Sommerprüfung 2022 (Fachinformatiker:in Anwendungsentwicklung) – IT-Berufe-Podcast #177
12 Sep 2022
01:05:17
Einen Rückblick auf die Fachgespräche (Fachinformatiker:in Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung im Sommer 2022 gibt es in der einhundertsiebenundsiebzigsten Episode des IT-Berufe-Podcasts.
Inhalt
Fachgespräche Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung)
Disclaimer: Meine Erfahrungen aus den Prüfungen, an denen ich beteiligt war, ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland.
Viele der genannten Themen für das Fachgespräch gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben (insb. die wirtschaftlichen Themen).
Fast immer falsch beantwortet wurden Fragen nach Stundensatz, laufenden Kosten, Lösch-Anomalie, Lambda-Ausdrücken, generischen Klassen.
Häufige Fragen im Fachgespräch
Das hier ist meine Liste mit den häufigsten Fragen im Fachgespräch für Fachinformatiker:innen Anwendungsentwicklung, absteigend nach Anzahl sortiert.
Man erkennt deutlich, dass unter der Top-Themen sehr viele Wirtschaftsthemen sind, weil viele „Techniker:innen“ diesen Bereich bei der Prüfungsvorbereitung vernachlässigen und dementsprechend in Projektdokumentation und Projektpräsentation falsch machen, was dann entsprechende Fragen im Fachgespräch provoziert.
Viele der anderen Themen ergeben sich aus Technologien, die die Prüflinge selbst eingesetzt haben. Ich sage immer wieder: Alles, was man benutzt (oder in der Projektpräsentation erwähnt), muss man auch erklären können. Da viele Projekte aktuell als Single-Page-Application in JavaScript mit einer anderen Programmiersprache im Backend (z.B. Java) umgesetzt werden, kommen z.B. Fragen nach REST, OAuth, Typisierung und JavaScript-Spefizika immer öfter vor.
Der Einfachheit halber habe ich die MP3 auch an diesen Beitrag angehängt. Dadurch erscheint sie automatisch im Feed des Anwendungsentwickler-Podcasts.
Für den Fachinformatiker-Podcast habe ich diesen RSS-Feed angelegt, damit du ihn nicht nur auf der Website, sondern auch im Podcatcher anhören kannst: http://fiae.link/FIPodcastRSS
Wenn dein Unternehmen dich nicht gut betreut, such dir ein anderes und leg Beschwerde bei deiner IHK ein.
Rückblick auf die Fachgespräche der Sommerprüfung 2016 – Anwendungsentwickler-Podcast #69
01 Aug 2016
00:34:28
Einen kurzen Rückblick auf meine „Highlights“ der Fachgespräche der Sommerprüfung 2016 gibt die neunundsechzigste Episode des Anwendungsentwickler-Podcasts.
Inhalt
Der Datenschutz ist für viele Prüflinge ein Mysterium.
Genauso wie der (eigene) Stundensatz.
Grundlegende Testverfahren und weitere Verfahren der Qualitätssicherung wie Code Reviews sind häufig nicht bekannt.
MVC ist der Architekturklassiker, der fast nie sauber erklärt werden kann.
Basiswissen zum Encoding ist nicht vorhanden.
Kanban ersetzt so langsam Scrum. Aber niemand kann es erklären. Nicht einmal die Basics wie das WIP-Limit.
Seltsamerweise arbeiten alle inzwischen agil, aber niemand weiß, was das ist. Grundlegende Werte (z.B. Feedback, Mut) und Praktiken (z.B. TDD, Pair Programming) sind völlig unbekannt.
Sinnvolle Beispiele für 1:1-Beziehungen können nicht genannt werden.
Jeder nutzt Generics, aber niemand kann sie erklären.
Highlights
Trotz Einsatz von Java EE waren JPA und JSF dem Prüfling nicht bekannt.
Basisfragen zur Objektorientierung konnten trotz Wiederholung in der Berufsschule eine Woche zuvor (!) nicht beantwortet werden.
Das in der Doku erwähnte „Deployment-Diagramm“ (mit 3h eingeplant) war dem Prüfling gar nicht bekannt.
Der Objective-C-Programmierer konnte keine Pointer erklären, obwohl in seinem Code-Beispiel mindestens 10 verwendet wurden.
Du suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.
Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.
Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.
Buchclub: Handbuch für Fachinformatiker (Teil 7: HTML und CSS) – Anwendungsentwickler-Podcast #68
25 Jul 2016
00:35:09
Das Kapitel 18 (Webseitenerstellung mit (X)HTML und CSS) des IT-Handbuch für Fachinformatiker* ist Thema der achtundsechzigsten Folge des Anwendungsentwickler-Podcasts.
Inhalt
Das Kapitel enthält viele wichtige Grundlagen zur Webentwicklung. Insbesondere HTML5 und CSS3 sollte jeder Anwendungsentwickler für die Prüfung kennen.
Rückblick auf die Projektpräsentationen der Sommerprüfung 2016 – Anwendungsentwickler-Podcast #67
18 Jul 2016
00:25:49
Einen kurzen Rückblick auf meine „Highlights“ der Projektpräsentationen zur Sommerprüfung 2016 gibt die siebenundsechzigste Episode des Anwendungsentwickler-Podcasts.
Inhalt
Guter Augenkontakt und sicheres Auftreten bei den meisten Prüflingen.
Viele Prüflinge halten sich zu lange mit einzelnen Projektphasen/Problemen auf.
Oft so gut wie keine Technik auf den Folien.
Immer noch erstaunlich viele grottige Textfolien…
…natürlich aufgehübscht mit Cliparts.
Teils werden riesige, kaum zu erkennende Tabellen auf die Folien gepackt.
Rechtschreibfehler auf Folien gehen gar nicht.
Erstaunlich oft nur 10 Minuten Präsentation. Und wichtige Inhalte fehlen leider.
Bilder mit Wasserzeichen werden pixelig hochskaliert auf den Folien verwendet.
Highlights
„Kosten dürfen aufgrund des Datenschutzes nicht gezeigt werden.“
Buchclub: Handbuch für Fachinformatiker (Teil 6: Webserver und -anwendungen) – Anwendungsentwickler-Podcast #66
11 Jul 2016
00:43:45
Die Kapitel 14, 15 und 19 (Server für Webanwendungen, Weitere Internet-Serverdienste und Webserveranwendungen) des IT-Handbuchs für Fachinformatiker sind Thema der sechsundsechzigsten Folge des Anwendungsentwickler-Podcasts.
Inhalt
Die drei Kapitel enthalten viele sinnvolle und hilfreiche Informationen für die Praxis, z.B. für die Einrichtung eines eigenen Linux-Servers. Für die IHK-Prüfung waren davon aber nicht ganz so viele Bereiche interessant, da dort weniger konkrete Produkte abgefragt werden.
In der nächsten Episode geht es um die Kapitel 18 und 20. Es gibt also die volle Breitseite HTML, CSS und JavaScript. 🙂
Dein eigener Webserver
Hast du auch schon einen eigenen Webserver? Wenn du mit dem Gedanken spielst, empfehle ich für den Einstieg 1blu*. Da bekommst du im ersten Jahr für 53,40 EUR einen kompletten vServer inkl. Domain und SSL-Zertifikat. ACHTUNG: Danach wird es etwas teurer: 7,90 EUR/Monat also 94,80 EUR/Jahr.
Für meine Studierendenprojekte an der PHWT nutze ich das Angebot bereits seit ein paar Jahren und bislang hat immer alles gut geklappt. Jedes Jahr lasse ich die Studierenden eine neue Recherche nach der günstigsten Lösung bei entsprechender Leistung durchführen und wir landen immer wieder bei 1blu*.
Kennst du einen noch besseren Hoster, den du anderen Azubis empfehlen kannst? Dann schreib mir gerne einen Kommentar!
Rückblick auf die Projektdokumentationen zur Sommerprüfung 2016 – Anwendungsentwickler-Podcast #65
04 Jul 2016
00:39:29
Einen kurzer Rückblick auf meine „Highlights“ der Projektdokumentationen zur Sommerprüfung 2016 gibt die fünfundsechzigste Episode des Anwendungsentwickler-Podcasts.
Inhalt
Plagiate nehmen Überhand. Insbesondere von dieser Seite. Dringende Warnung: Das kann die Note und/oder die Prüfung kosten!
Viele Dokumentationen nutzen die verfügbare Seitenzahl nicht aus.
Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.
Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.
Rückblick auf die schriftliche Sommerprüfung 2016 – Anwendungsentwickler-Podcast #64
30 May 2016
00:25:27
Da ich gerade frisch von der Korrektur der Klausuren komme, gehe ich in der vierundsechzigsten Episode des Anwendungsentwickler-Podcasts die Inhalte der schriftlichen Sommerprüfung 2016 durch.
Inhalt
Insgesamt eine absolut machbare Prüfung. Eigentlich keine überraschenden Inhalte. Viel Standardwissen, auf das man sich sehr gut vorbereiten konnte.
Ganzheitliche Aufgabe I
Die Klassiker: Projektmanagement, UML, Programmierung, Tabellenmodell, SQL
Erschreckend wenige Prüflinge beherrschen die Basis-UML-Diagramme!
Programmieraufgabe war recht umfangreich.
Tabellenmodell war absoluter Standard.
Ganzheitliche Aufgabe II
Viel anwendbares Mathe- und Rechnungswesen-Know-How gefragt.
Wenig Nischenwissen nötig.
Erschreckend wenige Prüflinge können Phishing und Spam bzw. Backup und Archivierung auseinanderhalten.
Literaturempfehlungen
Die Klassiker zur Vorbereitung auf die schriftliche Prüfung.
Du suchst noch mehr Tipps rund um die Vorbereitung auf die schriftliche IHK-Prüfung? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die schriftliche IHK-Prüfung.
Und kennst du schon meine Übungsaufgaben für die Abschlussprüfung? Unter dieperfekteihkpruefung.de kannst du sie herunterladen.
Hörbuch zur Vorbereitung auf das Fachgespräch – Anwendungsentwickler-Podcast
25 May 2016
00:31:12
Gerade rechtzeitig zur Sommerprüfung 2016 habe ich ein Hörbuch zur Vorbereitung auf das Fachgespräch aufgenommen. In fast 5 Stunden (4:45 um genau zu sein 😉 ) gehe ich über 100 Fragen durch, die im Fachgespräch zu den Themengebieten Programmierung und Objektorientierung gestellt werden könnten.
Wenn du Interesse am Hörbuch hast, schau doch mal auf der Website vorbei: Das perfekte Fachgespräch.
Um dir einen Eindruck der Inhalte zu vermitteln, habe ich für diesen Beitrag eine separate Podcast-Episode aufgenommen, die ein komplettes Probekapitel des Buchs enthält. Ich beantworte darin die folgenden Fragen:
Was ist ein Objekt?
Was ist eine Klasse?
Was ist der Unterschied zwischen Objekt und Klasse?
Was sind die Member einer Klasse?
Was sind statische Member?
Was sind Vor-/Nachteile von statischen Methoden?
Was bedeutet Instantiierung?
Wie instantiiert man ein Objekt?
Was ist eine Instanzvariable?
Wie kann man Instanzvariablen initialisieren?
Was ist ein Feld?
Was ist eine Methode?
Was bedeutet es, eine Nachricht an ein Objekt zu senden?
Wie referenziert man im Code das aktuelle Objekt?
Hör doch mal rein!
Über Feedback zum Hörbuch würde ich mich sehr freuen! Ich hoffe, ich kann damit ein paar Prüflingen die Angst vor dem Fachgespräch und den bösen Prüfern nehmen! 🙂
Du suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.
Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.
Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.
Vorbereitung auf das Fachgespräch – Anwendungsentwickler-Podcast #63
23 May 2016
00:45:41
Da viele Prüflinge großen Respekt vor dem Fachgespräch haben, gibt es in der dreiundsechzigsten Episode des Anwendungsentwickler-Podcasts einige Tipps zur Vorbereitung auf diesen Teil der mündlichen Prüfung.
Inhalt
Nachdem die schriftliche Prüfung geschafft ist, stehen viele Prüflinge vor der nächsten großen Aufgabe: der Vorbereitung auf die mündliche Prüfung. Nach der Projektpräsentation, die man komplett in der eigenen Hand hat, steht das mit Spannung erwartete Fachgespräch an.
Jedes Mal, wenn es wieder auf die Prüfungszeit zugeht, häufen sich die Fragen in den einschlägigen Foren:
Was werden die Prüfer fragen? Welche Themen kommen dran? Wie soll ich mich vorbereiten?
Um nicht immer wieder dasselbe erzählen zu müssen, schreibe ich im Folgenden mal zusammen, wie man sich sinnvollerweise auf das Fachgespräch vorbereiten sollte.
Mögliche Themen im Fachgespräch
Grundsätzlich können die Prüfer im Fachgespräch alle möglichen Themengebiete der Prüfung abfragen. Es gibt also nicht – wie häufig behauptet wird – eine Einschränkung auf die Themen des eigenen Abschlussprojekts. Man muss sich letztlich auf alle potentiellen Themen vorbereiten. Aber das hat man als Prüfling ja auch schon für die schriftliche Prüfung getan. Und zwar hoffentlich mit ausreichend Vorlauf, sodass die Inhalte nicht am Tag nach der Prüfung wieder aus dem Kopf verschwunden sind. Denn bis zur mündlichen Prüfung vergehen durchaus mehrere Wochen. Und wenn dann alles Gelernte wieder weg ist, darf man nochmal von vorne anfangen. Aber dazu mehr hier: Vorbereitung auf die schriftliche Abschlussprüfung.
Also gilt genau wie für die schriftliche Prüfung meine Empfehlung: Fang früh an zu lernen und wiederhole die Inhalte regelmäßig. Dadurch kannst du sie nicht nur in der schriftlichen Prüfung abrufen, sondern auch in der mündlichen. Und ganz nebenbei kannst du sie vielleicht sogar im Arbeitsalltag anwenden, was ja letztlich das Ziel der Ausbildung sein sollte. 😉
Keine Einschränkung auf die Themen des eigenen Abschlussprojekts.
Wahrscheinliche Themen im Fachgespräch
Ich kann natürlich nicht für alle Prüfungsausschüsse sprechen, aber es kristallisieren sich meiner Meinung nach einige Standardthemen heraus, mit denen man als Anwendungsentwickler/in im Fachgespräch rechnen sollte. Ich halte es für unwahrscheinlich (und auch unsinnig), Anwendungsentwickler über strukturierte Verkabelung oder Netzwerktopologien zu befragen. Ich würde mich als Prüfer stattdessen auf die Kernkompetenzen konzentieren. Und das sind meiner Meinung nach:
Aber es gibt auch noch einen großen anderen Bereich an potentiellen Themen, den man nicht unterschätzen sollte: das eigene Abschlussprojekt. Obwohl die Prüfer nicht auf Fragen aus dem Bereich des Projekts begrenzt sind, werden viele sicherlich das Projekt als Aufhänger nehmen, um ins Fachgespräch einzusteigen. Daher sollte man sein Projekt in- und auswendig beherrschen und z.B. alle verwendeten Fachbegriffe einwandfrei erklären können.
Eigene Projektdokumentation und -präsentation
Eine einfache Aufgabe in Vorbereitung auf das Fachgespräch ist es daher, die eigene Projektdokumentation und insb. die -präsentation auf mögliche Prüfungsinhalte zu durchforsten. Dazu zählen insb.:
Verwendete Fachbegriffe (insb. Definitionen für Abkürzungen)
Verwendete Technologien (z.B. ORM, MVC, ERM)
Details zum Projektablauf (z.B. Zeitplanung, Vorgehensmodell)
Schnittstellen des Projekts (fachlich und technisch)
Datenschutz und -sicherheit bezogen auf das Projekt (wird häufig vergessen)
Pro-/Contra-Bewertung der verwendeten Technologien (z.B. Performance, Kosten, Komplexität)
Im Fachinformatiker-Forum habe ich den Tipp gelesen, sich auf Basis der eigenen Artefakte eine Mindmap aller potentiellen Themen zu erstellen, indem man zunächst einfach nur die verwendeten Begriffe, Technologien usw. in einen Zusammenhang stellt und im nächsten Schritt dann den Assoziationen freien Lauf lässt:
Was fällt dir noch zu den Begriffen ein? (z.B. REST zu SOAP, JSON zu XML)
Was sind mögliche Ergänzungen? (z.B. AJAX bei Webprojekt, Rich Client)
Was sind Gegensätze oder Alternativen zu den Begriffen? (z.B. Java vs. .NET, Web vs. Fat Client)
Am besten führst du dieses Brainstorming nicht alleine durch, sondern holst dir andere ITler zur Hilfe: Ausbilder/in, Mitschüler/innen, Mitazubis, Kollegen/innen, Chef/in usw. Mehr Köpfe kommen sicherlich auf mehr Ideen. Gerade auch scheinbar Unbeteiligte bringen dich vielleicht auf Ideen: der Chef fragt nach der Amortisation, die Kunden nach der Usability, die Kollegen nach verwendeten Design Patterns usw.
Häufige Themenbereiche
Wenn du trotzdem noch weitere Anregungen brauchst, dann schau mal in den üblichen Foren nach: fachinformatiker.de
Dort wirst du sicherlich einige Beiträge finden, in denen mögliche Fragen zu verschiedenen Projekten diskutiert werden.
Wie bereits angedeutet, gibt es auch immer wieder Themen, die die Prüflinge gerne man „vergessen“. Ob absichtlich oder aus Versehen, sei mal dahingestellt. 😉 Hier kommt eine (unvollständige) Liste:
Man kann als Prüfling auch ein wenig Einfluss auf die Fragen der Prüfer nehmen. Wenn man z.B. bestimmte Sachverhalte in der Projektpräsentation (die direkt vor dem Fachgespräch stattfindet) besonders betont, kann das die Prüfer dazu anregen, mal nachzufragen. Dann sollte man sich aber natürlich auch bestens in diesem Bereich auskennen!
Ich habe schon oft die Geschichte vom Prüfling erzählt, der in der Präsentation den Satz brachte „Ich habe als Architekturprinzip MVC verwendet. Vielleicht werde ich ja gleich dazu befragt.“ und dann aber keine Ahnung vom Thema hatte. Das war schon recht witzig. Auch nett war der Prüfling, der unter Extreme ProgrammingProgrammieren ohne Regeln verstand.
Gerade in den Quelltext, der an der Dokumentation hängt, schaue ich als Prüfer immer sehr gerne. Dort finde ich nämlich meist viele Sachen, die der Prüfling zwar verwendet, aber gar nicht verstanden hat. Und moderner Quelltext strotzt nur so vor Lamdas, LINQ-Abfragen, generischen Klassen usw. Und all das sollte man – fachlich korrekt – erklären können.
Die mündliche Prüfung simulieren
Zu guter Letzt bleibt noch zu empfehlen, die mündliche Prüfung – am besten mehrfach – zu simulieren. Dafür steht dir dein/e Ausbilder/in sicherlich zur Seite.
Allein die Präsentation solltest du ohnehin mehrfach durchspielen und dann am besten direkt im Anschluss das Fachgespräch üben. Lade auch ruhig Zuhörer ein, die dein Projekt nicht kennen. Nur dadurch fallen nämlich noch Sachverhalte auf, die du nicht verständlich erklärt hast. Gehe nicht davon aus, dass all deine Prüfer deine Dokumentation gelesen haben. Das ist selten der Fall. Du musst also in der Präsentation alles so erklären, dass die Zuschauer es ohne Vorwissen (bezogen auf das Projekt, nicht auf die IT allgemein) verstehen können.
Und da du selbst sehr tief in der Materie deines Projekts steckst, fallen dir offensichtliche Fragestellungen ggfs. gar nicht mehr auf. Also nutze die – meist wochenlange – Vorbereitungszeit auf die mündliche Prüfung und quäle deine Kollegen mit Präsentationen und Fragerunden. So bekommst du bestimmt noch viele Anregungen für mögliche Fragen der Prüfer.
Antworten trainieren
Bei der Gelegenheit kannst du auch gleich üben, die Fragen vernünftig zu beantworten. Wir wollen korrekte, kurze, präzise und gut strukturierte Antworten hören und nicht minutenlanges Rumgelaber ohne zum Punkt zu kommen. Beispiele dafür findest du in meinen Podcast-Episoden.
Aber es geht nichts über das direkte Training mit deinem/r Ausbilder/in, der/die dir konkretes Feedback zu deinen Formulierungen gibt. Es geht nicht darum, Antworten auswendig zu lernen, sondern die Inhalte verständlich und sauber definiert rüberzubringen. Auswendig gelernte Antworten erkennen wir als Prüfer recht schnell und stellen dann direkt die passenden Fragen, um zu prüfen, ob zusätzlich auch echtes Verständnis da ist. Also bitte deine/n Ausbilder/in darum, das Fachgespräch zu üben, wenn er/sie das nicht von sich aus vorschlägt.
Allgemeine Tipps
Unterschätze nicht die Anforderungen.
Fange früh an zu lernen.
Nutze Synergieeffekte durch die Vorbereitung auf die schriftliche Prüfung.
Erstelle eine Mindmap mit Themen des eigenen Projekts.
Was fällt dir noch zu den Begriffen ein? (z.B. REST zu SOAP, JSON zu XML)
Was sind mögliche Ergänzungen? (z.B. AJAX bei Webprojekt, Rich Client)
Was sind Gegensätze oder Alternativen zu den Begriffen? (z.B. Java vs. .NET, Web vs. Fat Client)
Sammle gemeinsam mit Kollegen/Ausbilder/Chef/Mitschülern Fragen und simuliere das Fachgespräch. Je mehr Hinweise du bekommst, desto besser.
Übe am besten die Projektpräsentation und direkt im Anschluss das Fachgespräch.
Übe die Formulierung der Antworten auf Standardfragen.
Lerne die Antworten nicht auswendig.
Steuere die Prüfer in die gewünschte Richtung.
Bleib ruhig. Die Prüfer sind meistens sehr nett. 😉
Fazit
Mit der richtigen Vorbereitung muss das Fachgespräch kein Grund zur Sorge sein. Im Gegenteil: Durch die Interaktivität des Gesprächs lassen sich kleine Fehler auch wieder ausbügeln oder Fragen zu nicht verstandenen Aufgaben stellen.
Letztlich sind die Prüfer auch nur Menschen und wollen den Prüflingen nichts Böses, sondern sie gut durch die Prüfung bringen. Aber wir erwarten auch ein fundiertes Fachwissen und gut vorbereitete Prüflinge! Also zack zack, an die Arbeit! 😀
Du suchst noch mehr Tipps rund um das Fachgespräch? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um das Fachgespräch.
Kennst du schon meine Hörbücher zur Vorbereitung auf das Fachgespräch? Unter dasperfektefachgespraech.de kannst du sie herunterladen. In insg. über 10 Stunden gehe ich über 200 Fragen im Detail durch und gebe Tipps für die Beantwortung.
Und wenn du dich für meinen Newsletter einträgst, bekommst du immer direkt alle Neuigkeiten von dieser Seite in dein Postfach geliefert.
Ansprechende Gestaltung der Projektpräsentation – Anwendungsentwickler-Podcast #62
16 May 2016
00:46:26
Die ansprechende Gestaltung der Projektpräsentation ist das Thema der zweiundsechzigsten Episode des Anwendungsentwickler-Podcasts.
Inhalt
Mit der Projektpräsentation kannst du deine Endnote stark beeinflussen. Sie zählt nicht nur 25% der Note von Teil A, sondern gibt auch die Richtung für das Fachgespräch vor. Daher kannst und musst du dich von deiner besten Seite zeigen. Oftmals hat ein Großteil des Prüfungsausschusses deine Dokumentation gar nicht gelesen und sieht dich ausschließlich in der Präsentation (und dem anschließenden Fachgespräch). Also widme ihr die gebührende Vorbereitungszeit!
Achtung: Wenn deine IHK konkrete Vorgaben bzgl. Inhalt, Zielgruppe, Gestaltung usw. der Projektpräsentation macht, dann halte dich unbedingt daran!
Allgemeine Tipps
Picke dir nur die Highlights deines Projekts raus und unterstreiche diese durch entsprechende Abbildungen, Diagramme, Graphen.
Zeige dein methodisches Vorgehen. Das heißt: UML, ERM, MockUps, EPKs, Netzplan, Quelltext von coolen Algorithmen, Screenshots usw.
Den Aufbau würde ich relativ klassisch strukturieren, z.B. in Projektumfeld, Projektidee, Projektrealisierung und Projektergebnis.
Auf keinen Fall die Technik (= UML, ERM usw.) und Wirtschaftlichkeit (= Kosten, Amortisation usw.) vergessen!
Die Präsentation ist keine Verkaufsshow! Weder für dein Produkt, noch für dein Unternehmen.
Verlasse dich nicht auf funktionierendes Internet oder Technik!
Konkrete Gestaltungstipps
Auf ein stimmiges Gesamtbild (Farben, Schrift, Animationen immer gleich) achten.
Alle Texte und insb. Quelltexte und auch Grafiken müssen gut lesbar sein. Zoome ggfs. in wichtige Bereiche rein.
Ich empfehle als Folienformat 4:3.
Folien dritteln (Hilfslinien nutzen) und die Inhalte optisch ansprechend platzieren.
Ich würde wenn immer es geht, einen hellen Hintergrund und eine dunkle Schrift benutzen. Denn viele Beamer sind leider etwas schwach im Kontrast und bei umgekehrter Farbwahl erkennt man dank „grauem“ Hintergrund dann nichts mehr.
Bilder sind immer besser als Text.
Vorstellung des Azubis und des Unternehmens mit Fotos der Mitarbeiter oder des Gebäudes.
Fotos der bisherigen Papierdokumente bei der Ist-Analyse.
Architektur der Anwendung mit UML-Diagrammen verdeutlichen.
Mockups und Screenshots der Anwendung zeigen.
Cliparts sind gruselig!
Kein Corporate Design verwenden, sondern das Layout, das den Inhalt am besten transportiert. Ich würde gar keine Vorlage nehmen, sondern mit den weißen Folien anfangen. Weg mit dem Firmenlogo, der Seitenzahl und dem Datum auf jeder Folie! Rein mit den bildschirmfüllenden Grafiken, Bildern, Diagrammen usw.!
Das CI kann auch mit Farben usw. des Unternehmens umgesetzt werden.
Animationen sparsam und sinnvoll einsetzen, z.B. zur Unterstützung der Inhalte (Text/Grafiken nacheinander einblenden).
Keine mitlaufende Agenda verwenden (nimmt zu viel Platz weg), sondern Zwischenfolien.
Datenschutz beachten. Aber Daten nicht schwärzen, sondern durch Pseudodaten austauschen.
Vielleicht kannst du Videos der fertigen Anwendung einbauen.
Sonstiges
Du brauchst kein Handout!
Halte unbedingt die vorgegebene Zeit ein!
Das Tool (PowerPoint, Prezi usw.) ist irrelevant.
Beispielpräsentationen
Literaturempfehlungen
Der Präsentationsmeister Garr Reynolds zeigt in Presentation Zen Design* viele praxisnahe Tricks und Gestaltungsmerkmale für ansprechende Präsentationsfolien. Eine absolute Leseempfehlung! *
Nancy Duarte, die mit ihrem Unternehmen Duarte Design einen Oscar für die Präsentation von Al Gore in An Inconvenient Truth* bekommen hat, gibt in Slide:ology* viele praktische Tipps für ein ansprechendes Foliendesign. *
Rückblick auf die Projektpräsentationen der Sommerprüfung 2022 (Fachinformatiker:in Anwendungsentwicklung) – IT-Berufe-Podcast #176
29 Aug 2022
01:06:44
Einen Rückblick auf die Projektpräsentationen (Fachinformatiker:in Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung im Sommer 2022 gibt es in der einhundertsechsundsiebzigsten Episode des IT-Berufe-Podcasts.
Inhalt
Projektpräsentationen Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung)
Disclaimer: Meine Meinung ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland.
Ich schaue insbesondere auf die Gestaltung der Folien und den Vortrag, aber wichtig sind natürlich auch die fachlichen/technischen Inhalte der Präsentation.
Einzelne Punkte auf der folgenden Liste führen nicht zwangsläufig zu Punktabzug bei der Note, aber oft treten mehrere Punkte gemeinsam auf, was dann einen Punktabzug rechtfertigt.
Viele „Probleme“ mit den Projektpräsentationen gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben.
Foliengestaltung und Vortrag
Oft wurden Punktlisten nicht Schritt-für-Schritt eingeblendet, sondern sofort als Ganzes gezeigt.
(Unnötige) Kopfzeile in einer Präsentation war winzig klein.
Cliparts für die Darstellung des Ist-Zustands, anstatt eigene Fotos zu machen.
Präsentationen vom selben Unternehmen sahen fast identisch aus und hatten auch einen sehr ähnlichen Aufbau.
Der Text auf den Folien war oft sehr klein und kaum lesbar.
(Offensichtliche) Rechtschreibfehler auf den Folien.
Tortendiagramme sahen in fast allen Präsentationen identisch aus (Standardfarben von PowerPoint genutzt).
Vorstellung des Prüflings: graue Silhouette statt Bild verwendet.
Präsentation mit LaTeX erstellt, aber leider ausschließlich Textfolien.
Code wurde durch Zeigen an der Leinwand erklärt, anstatt ihn visuell hervorzuheben.
Prüfling kommentierte die Vorstellung des Unternehmens mit „hier habe ich mal statt des klassischen Bildes unsere Azubis genommen“.
Ein Prüfling hat die Architektur seiner Anwendung an die Tafel gezeichnet.
Einige Prüflinge haben stark abgelesen und kaum Blickkontakt zum Prüfungsausschuss gehabt.
Fehlende/unnötige Inhalte
Oft wurden die Artefakte aus der Projektdokumentation nicht in der Projektpräsentation gezeigt.
Oft werden Inhalte genannt, aber nicht visualisiert (z.B. 3-Schichten-Architektur ohne Grafik).
Angeblich erstellte Artefakte werden erwähnt, aber nicht gezeigt.
Teilweise wurde viel zu detailliert auf Code eingegangen.
Das Ziel des Projekts wird oft nicht deutlich.
Jedes genutzt JavaScript-Package wurde inkl. Versionsnummer aufgeführt und erklärt.
Ein Prüfling hat jede verwendete Technologie ausführlich erklärt (z.B. Kafka und Kubernetes).
Scrum wurde in einer Präsentation ausführlich erklärt.
Sonstiges
Notepad++ als IDE verwendet.
Deployment als Upload auf einen FTP-Server.
Einige Prüflinge haben den Prüfungsausschuss geduzt.
Prüfling mit Mac hatte keinen Adapter für HDMI dabei.
Prüfling hat einen Programmablaufplan erstellt, anstatt ein UML-Diagramm zu nutzen.
Einige Unternehmen entwickeln wohl auf Englisch, aber niemand schaut auf die korrekten Vokabeln.
Mögliche/erwartete Artefakte
Die folgenden Artefakte sind in einer Projektpräsentation möglich bzw. ich würde sie in einer „sehr guten“ Arbeit erwarten. Auch hier gilt: Wenn mal eines oder mehrere der Artefakte fehlen, heißt das nicht automatisch, dass eine schlechte Note folgt. Es geht immer auch um den Gesamteindruck der Präsentation inkl. Gestik, Mimik usw.
Buchclub: Handbuch für Fachinformatiker (Teil 5: Betriebssysteme, Windows und Linux) – Anwendungsentwickler-Podcast #61
09 May 2016
00:45:13
Die Kapitel 5 bis 7 (Betriebssystemgrundlagen, Windows und Linux) des IT-Handbuchs für Fachinformatiker sind Thema der einundsechzigsten Folge des Anwendungsentwickler-Podcasts.
Inhalt
Die drei Kapitel enthalten dieses Mal wenig prüfungsrelevante Inhalte, dafür sehr viel Praxis. Ich wünschte, ich hätte die Kapitel schon vor einigen Monaten mit meinen Auszubildenden gelesen. Gerade die Inhalte von Kapitel 7 zum Thema Linux hätten meine Azubis direkt bei der Installation Ihrer Linux-Server anwenden können.
Ergonomie am Arbeitsplatz – Anwendungsentwickler-Podcast #60
02 May 2016
00:56:45
Um am Arbeitsplatz lange gesund zu bleiben, gibt es eine Vielzahl von ergonomischen Eingabegeräten und Büromöbeln. In der sechzigsten Episode des Anwendungsentwickler-Podcasts zeige ich, wie mein Büro aussieht, und gebe Tipps für ergonomisches Arbeiten.
Inhalt
Hardware
Auf der Arbeit habe ich einen höhenverstellbaren Schreibtisch.
Zu Hause arbeite ich mit einem höhenverstellbaren „Roboterarm“, dem Ergotron Workfit*.
*
Wer nicht so viel Geld in den Schreibtisch investieren möchte, der kann sich für wenig Geld einen Stehschreibtisch selbst bauen (siehe Warum ich meinen Schreibtisch entsorgt habe von Markus Cerenak).
Egal ob du einen Stehschreibtisch hast oder nicht, wichtig ist, dass du oft deine Position wechselst.
Mein Bürostuhl ist der Topstar Open Art*. Er lässt sich sehr flexibel einstellen und ist bequem und ergonomisch. *
Auf die Lehnen meines Bürostuhls habe ich weiche Ellenbogen-Auflagen montiert.
Wenn du zwei Monitore verwendest, achte darauf dass einer von beiden gerade vor deinem Gesicht platziert wird. Ansonsten hast du immer eine leichte Schräghaltung und das ist nicht gut für deinen Nacken.
Es gibt sogar einen Monitor, der dir Vorschläge zu deiner Körperhaltung macht. Ich habe ihn jedoch noch nicht selbst getestet. *
Auf dem obigen Foto siehst du tatsächlich meinen Arbeitsplatz. Ich habe zwei vertikale Mäuse, jeweils eine für die linke* und die rechte* Hand. *
Als Mausunterlage verwende ich ein – bzw. zwei 😉 – ergonomisches Mauspad* mit Handballenauflage. *
Eine „perfekte“ Tastatur soll die Kinesis KIN-ADVWUSBHY* sein. Leider konnte ich sie noch nicht selbst testen. *
Auch Sauberkeit zähle ich zur gesunden Arbeit dazu. Reinige regelmäßig deine Eingabegeräte. Ich desinfiziere zum Beispiel alle zwei Wochen Maus und Tastatur mit Reinigungstüchern.
Software
Wer abends lange am PC arbeitet kann danach meist nur schlecht einschlafen. Die kostenfreie Software f.lux hilft dabei, indem sie die blauen Anteile des Lichts aus dem Monitor filtert.
Das gleiche geht auch mit dem Handy. Die entsprechende kostenlose Software heißt Twilight.
Um deine Arbeit in Pomodoros einzuteilen, ist ebenfalls kostenlose Software hilfreich. Ich verwende z.B. Clockwork Tomato auf dem Handy und Flowkeeper auf dem PC.
Wenn du häufig Texte tippen musst, dann schau dir als Alternative zum Tippen doch einmal eine Spracherkennungssoftware an. Ich habe diesen Text zum Beispiel in mein Android-Handy diktiert, und den Text danach nur noch kurz überarbeitet. Die Spracherkennung funktioniert heutzutage wirklich sehr gut und kann dir viel Tipparbeit abnehmen.
Tipps
Für regelmäßige Pausen und um daran erinnert zu werden, die Position zu verändern, kannst du die Pomodoro-Technik anwenden. In den Pausen kannst du auch gut ein paar kurze Übungen absolvieren (z.B. 18 geniale Tipps für mehr Bewegung am Arbeitsplatz).
Aber auch beim Tippen und bei der Arbeit mit der Maus ist Abwechslung wichtig. Fast alle für Softwareentwickler wichtigen Programme lassen sich sowohl mit der Tastatur, als auch mit der Maus steuern. Wechsel doch einfach mal das Eingabegerät.
Trink zwischendurch häufig Wasser. Auch das kannst du sehr gut mit der Pomodoro-Technik verbinden.
Da wir uns als Softwareentwickler ständig weiterbilden müssen, verbinde doch einfach Fortbildung und Gesundheit, indem du Lernvideos zum Beispiel auf dem Crosstrainer oder dem Laufband anschaust oder Podcast wie diesen während des Fitnesstrainings hörst.
Mach doch mal einen Gesundheitskurs – insb. für den Rücken – bei deiner Krankenversicherung oder der Volkshochschule mit. Meist reicht es schon, wenn du Ideen bekommst, was du ändern kannst.
Noch ein persönlicher Tipp bezüglich der Ernährung: Green Smoothies sind schnell zubereitet, lecker und eine gesunde Alternative zu Cola. Von der Autorin der Healthy Smoothie Bible* habe ich zum ersten Mal beim – sehr empfehlenswerten – Read to Lead Podcast gehört.
Und noch zwei kleine Tipps für mehr Bewegung. Parke dein Auto so weit weg wie möglich vom Eingang deines Unternehmens. Dadurch musst du wenigstens etwas mehr Bewegung an den Tag legen. Und wenn du die Toilette besuchst, nimm doch einfach die im anderen Geschoss deines Gebäudes. So baust du ein paar Treppenstufen in Deinen Alltag ein. Kleinigkeiten machen schon einen Unterschied.
Literaturempfehlungen
Mein Buchtipp Nummer 1 ist The Healthy Programmer*. Darin findest Du noch viele weitere Tipps und Hinweise zum gesunden Arbeiten. Der Autor überträgt z.B. die testgetriebene Softwareentwicklung auf die Gesundheit. So prüfst du mit Unit-Tests deinen Gesundheitszustand. *
Das Buch zur Pomodoro-Technik habe ich schon mehrfach in meinen Artikeln verlinkt und kann es absolut weiterempfehlen. Es ist sehr kurzweilig und wird deinen Arbeitsalltag eventuell komplett verändern. *
Viele tolle – und vor allem leckere – Smootie-Rezepte gibt es hier: *
Zwei sehr empfehlenswerte Podcasts zum Thema Gesundheit sind The Model Health Show von Shawn Stevenson – der auch ein tolles Buch zum Thema Schlafen* geschrieben hat – und das inzwischen leider eingestellte Get Up And Code. *
In der c’t* erschien in Ausgabe 24/2015 ein guter Artikel zu ergonomischen Büromöbeln: Ergonomisch arbeiten: Wie Sie trotz Bürojob fit bleiben.
Buchclub: Handbuch für Fachinformatiker (Teil 4: TCP/IP) – Anwendungsentwickler-Podcast #59
25 Apr 2016
00:38:34
Wir beenden das Thema Netzwerkgrundlagen im Rahmen des Buchclubs zum Handbuch für Fachinformatiker von Sascha Kersken in der neunundfünfzigsten Episode des Anwendungsentwickler-Podcasts.