Um die Relevanz von Pseudocode-Aufgaben in den IHK-Prüfungen für Anwendungsentwickler:innen, aber auch für Systemintegrator:innen, und wie man sie am besten löst geht es in der einhundertfünfundneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt
In dieser Episode des IT-Berufe-Podcasts thematisiere ich Pseudocode-Aufgaben, die häufig Teil der schriftlichen IHK-Prüfungen sind, und das nicht nur für Anwendungsentwicklerinnen, sondern auch für andere Fachinformatiker und insb. Systemintegratoren. Ich gehe darauf ein, warum diese Aufgaben so zentral für die IT-Ausbildung sind und welche Relevanz sie für die Prüfenden haben. Die grundlegende Idee hinter den Pseudocode-Aufgaben ist es, das algorithmische Denken der Prüflinge zu fördern und zu prüfen. Mein Ziel ist es, dir zu helfen, dich optimal auf solche Prüfungen vorzubereiten.
Ich beginne damit, die Bedeutung von Pseudocode in den IHK-Prüfungen zu erläutern. Pseudocode stellt sicher, dass ein allgemeines Verständnis der Programmierung abgefragt wird, unabhängig von spezifischen Programmiersprachen. Dies ist wichtig, da die Prüfer in der Lage sein müssen, die Lösungen zu verstehen, egal welche Programmiersprache verwendet wird. Ich erkläre die grundlegenden Bausteine des Pseudocodes sowie die Anforderungen an die Korrektur durch die Prüfer.
Im weiteren Verlauf bespreche ich Strategien, um Pseudocode effektiv zu schreiben. Ich gebe dir Empfehlungen, wie du deine Lösungen strukturieren und formulieren kannst, um die maximale Punktzahl zu erzielen. Dabei sind klare Einrückungen und der Verzicht auf komplizierte Syntax entscheidend. Es wird auch geraten, grundlegende Algorithmen zu verwenden und keine spezifischen Features aus einer bestimmten Programmiersprache zu nutzen.
Neben der technischen Ausführung gehe ich auch auf die psychologischen Aspekte der Prüfungsvorbereitung ein. Ich ermutige dich, alte Prüfungen zu bearbeiten und regelmäßig zu üben, um ein Gefühl für die Aufgaben zu bekommen. Feedback von Ausbildern oder KI kann dir helfen, deine Fähigkeiten weiterzuentwickeln und häufige Fehler zu vermeiden. Ich teile häufige Problemstellungen, die in der Vergangenheit in Prüfungen aufgetreten sind, und zeige, wie du diese vermeiden kannst.
Abschließend lege ich großen Wert auf die Notwendigkeit, ein starkes algorithmisches Verständnis zu entwickeln. Der Fokus sollte nicht darauf liegen, die perfekte Programmiersprache zu beherrschen, sondern darum, Probleme effizient zu lösen und zu verstehen, welche Algorithmen und Logiken hinter den Aufgaben stehen. Ich hoffe, dass diese Episode dich inspiriert und dir hilft, dich optimal auf deine bevorstehenden Prüfungen vorzubereiten.
Wie schreibt man Pseudocode?
In letzter Zeit habe ich von vielen Prüflingen die Frage gestellt bekommen, ob ich nicht eine Einführung in das Schreiben von Pseudocode geben könnte. Ich frage dann immer direkt zurück, was denn so schwierig an Pseudocode sei. Ich würde für die Programmieraufgaben in der Abschlussprüfung immer Pseudocode verwenden und niemals eine grafische Darstellung wie das Aktivitätsdiagramm. Die Diagramme sind meist deutlich aufwändiger zu erstellen und bei Fehlern sehr schwer zu korrigieren. Mit Pseudocode ist das deutlich einfacher. Dennoch scheinen viele Azubis Probleme mit Pseudocode zu haben.
Standards
Erst durch eine Mail eines Zuhörers habe ich erfahren, dass es sogar Standards für Pseudocode gibt (z.B. Jana, Pascal-Style oder nach Leierson, siehe Pseudocode). Ich habe weder in meiner eigenen Prüfung noch in der Prüfungsvorbereitung mit meinen Azubis das Thema Pseudocode jemals intensiv behandelt. Ich empfehle immer, anstatt sich eine eigene Syntax für den Pseudocode auszudenken, einfach normalen Code in der Prüfung zu schreiben.
Da es für Pseudocode keine allgemeinverbindlichen Vorgaben in der Prüfung gibt,

Ich analysiere die erste AP1-Prüfung nach dem neuen Prüfungskatalog in der einhundertvierundneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt
In dieser Episode des IT-Berufe-Podcasts analysiere ich die erste AP1-Prüfung nach dem neuen Prüfungskatalog, die am 25.03.2025 stattgefunden hat. Mein Ziel ist es, die Inhalte dieser Prüfung zu diskutieren und wertvolles Feedback für die zukünftigen Prüflinge zu geben. Ich beginne mit einem Überblick über die Reaktionen und Ängste, die in der Vorbereitungszeit zirkuliert sind, und stelle klar, dass viele Bedenken unbegründet waren. Die Prüfung selbst war im Großen und Ganzen machbar und entsprach den Vorgaben des neuen Katalogs, ohne unangekündigte Überraschungen.
Ich gehe im Detail auf die einzelnen Themen und Aufgaben ein. Hierzu zählen unter anderem die Nutzwertanalyse, Rechenaufgaben, Hardware-Zuordnungen und Subnetting. Besonders hervorheben möchte ich die Nutzwertanalyse, die auch in dieser Prüfung wieder zahlreiche Punkte eingebracht hat. Es hat sich gezeigt, dass viele Aufgaben, trotz anfänglicher Unsicherheiten, gut zu bewältigen waren. Ich erläutere, dass diese Aufgaben durch logisches Denken und grundlegendes IT-Wissen gelöst werden konnten.
Ein weiterer wichtiger Aspekt war die IT-Sicherheit, die in verschiedenen Aufgabenformaten behandelt wurde. Ich betone die Relevanz der DSGVO in der Datenverarbeitung, insbesondere im Hinblick auf die rechtlichen Vorgaben beim Versand von E-Mails. Auch das Thema KI kam zur Sprache, wobei ich den Prüflingen empfehle, sich mit grundsätzlichen Anwendungsfeldern und ethischen Fragestellungen auseinanderzusetzen.
Ich werfe einen Blick auf den Schreibtischtest, wo die Prüflinge einfache Programmiersprachen und Algorithmen durchgehen mussten. Hier war es entscheidend, den Code Zeile für Zeile zu analysieren und die richtige Auswertung vorzunehmen. Diese Aufgaben sind für viele Prüflinge möglicherweise eine Herausforderung, aber mit den richtigen Vorbereitungsmaterialien sind sie machbar.
Zusätzlich gehe ich auf die Relevanz von Protokollen wie IMAP und POP3 ein und kläre die Unterschiede zwischen diesen wichtigen Technologien. Ich erläutere weiter, dass der von der Prüfung geforderte Wissenstand sowohl spezifisches Detailwissen als auch allgemeines Verständnis für IT-Themen erforderte.
Zusammenfassend lässt sich sagen, dass die AP1 eine faire Prüfung war, die weitestgehend den Erwartungen entsprochen hat. Ich mache den Zuhörern Mut, sich ebenfalls auf die kommenden Prüfungen gut vorzubereiten und die Angebote meiner Website zu nutzen, um stets auf dem neuesten Stand zu bleiben. Die Themen und Inhalte sind aktuell und gewährleisten eine optimale Vorbereitung für die nächsten Prüfungszyklen.
Links

* Permalink zu dieser Podcast-Episode
* RSS-Feed des Podcasts
* Nutzwertanalyse in der Projektdokumentation
* Subnetting mit IPv4 für Fachinformatiker:innen – IT-Berufe-Podcast bei YouTube
* Datenschutz vs. Datensicherheit vs. Datensicherung – IT-Berufe-Podcast #157
* Kryptographie – Schutzziele und...

Über den Unterschied zwischen Kauf, Miete und Leasing zur Finanzierung in Unternehmen geht es in der einhundertdreiundneunzigsten Episode des IT-Berufe-Podcasts.

Miete, Leasing oder Kauf – Welche Finanzierung passt zum Unternehmen?
Wenn Unternehmen teure Güter anschaffen müssen, stellt sich die Frage, wie diese finanziert werden sollen. Für die AP1 der IT-Berufe sind hier insbesondere die Unterschiede zwischen Kauf, Miete und Leasing interessant.
In dieser Episode des IT-Berufe-Podcasts beleuchte ich die Unterschiede zwischen Kauf, Miete und Leasing, und warum dieses Thema auch für die IT-Abschlussprüfung von Bedeutung ist. Als kaufmännischer Teil der IT-Ausbildung ist es unerlässlich, die verschiedenen Finanzierungsoptionen zu verstehen, besonders wenn es um größere Investitionen wie Fahrzeuge, Maschinen oder Server geht.
Zunächst analysiere ich die Kaufoption. Der Kauf eines Vermögenswertes bietet den Vorteil, dass dieser nach der Zahlung des Kaufpreises vollständig in den Besitz des Unternehmens übergeht. Hier bespreche ich die Vor- und Nachteile, beginnend mit der hohen Anfangsinvestition, die oft notwendig ist. Ich erkläre, wie Kredite funktionieren, einschließlich der verschiedenen Zinsarten und Rückzahlungspläne, die in der Regel über mehrere Jahre laufen. Diese Art der Finanzierung bringt die Verpflichtung mit sich, sich um das gekaufte Gut zu kümmern, was Instandhaltungskosten mit sich bringt. Ich gehe auch auf die Themen Steuerabschreibung und Wertverluste ein, die beim Besitz eines Vermögenswertes zu berücksichtigen sind.
Anschließend wende ich mich dem Thema Miete zu. Hier zeige ich auf, wie Miete mehr Flexibilität bietet, da Unternehmen in der Lage sind, kurzfristig auf Bedürfnisse zu reagieren, ohne große Anfangsinvestitionen zu tätigen. Bei der Mietung eines Fahrzeugs beispielsweise entfällt die Verantwortung für Wartung und Versicherung, was für Start-ups oder junge Unternehmen eine kostengünstige Lösung darstellen kann. Allerdings erödemie ich auch, dass die Miete langfristig die teuerste Option sein kann, da regelmäßige Zahlungen anfallen, ohne dass ein Eigentum entsteht.
Schließlich bespreche ich das Leasing, das eine besondere Form der Miete darstellt. Leasingverträge ermöglichen es Unternehmen, teure Investitionen über längere Zeiträume zu finanzieren, oft zu geringeren monatlichen Raten als bei Mietverträgen. Ich erläutere die typischen Laufzeiten und die Vorkaufsoptionen, die dem Leasingnehmer die Möglichkeit geben, das geleaste Objekt nach Ablauf des Vertrages zu kaufen. Zugleich beleuchte ich die Nachteile des Leasings, insbesondere die langfristige Bindung und die Tatsache, dass Leasing insgesamt teurer ist als ein Kauf, wenn das Asset über längere Zeiträume genutzt wird.
Abschließend fasse ich die verschiedenen Aspekte zusammen, um den Zuhörern ein klares Bild davon zu geben, unter welchen Umständen welche Finanzierungsform sinnvoll ist. Besonders die Prüfungsvorbereitung wird durch konkretes Beispiel-Rechnen und das Verständnis der Kriterien erleichtert, die bei der Entscheidung zwischen diesen Optionen zu beachten sind.
Kauf
Definition: Einmalige Investition für Eigentum an einem Produkt oder einer Dienstleistung.
Vorteile:

* Langfristig günstiger als Miete oder Leasing
* Volle Kontrolle und keine Vertragsbindung
* Abschreibungen und steuerliche Vorteile möglich
* Keine Einschränkungen bei Nutzung oder Anpassungen

Nachteile:

* Hohe Anfangsinvestition nötig
* Risiko von Wertverlust und Veralterung (besonders bei IT-Hardware)
* Wartung und Reparaturen gehen zulasten des Käufers

Praxisbeispiel: Kauf von Firmenlaptops oder Produktionsmaschinen
Miete
Definition: Kurzfristige Nutzung gegen regelmäßige Zahlungen ohne Eigentumserwerb.
Vorteile:

* Hohe Flexibilität (monatlich kündbar, kurze Laufzeiten)

Ich analysiere die schriftlichen IHK-Prüfungen AP1 und AP2 für Anwendungsentwicklung und präsentiere eine umfassende Übersicht der Prüfungsinhalte seit 2020 in der einhundertzweiundneunzigsten Episode des IT-Berufe-Podcasts.

In dieser Episode des IT-Berufe-Podcasts fokussiere ich mich auf die schriftlichen IHK-Prüfungen AP1 und AP2 für Anwendungsentwicklung und präsentiere eine umfassende Analyse der bisherigen Prüfungsinhalte. Dabei habe ich alle Prüfungen seit 2020 durchgeschaut und alle Themen sowie die vergebenen Punkte systematisch erfasst. Diese Informationen sind jetzt in einer übersichtlichen Datenbank zusammengeführt, die dir bei der gezielten Prüfungsvorbereitung helfen kann.
Ich beginne mit der Vorstellung der allgemeinen Prüfungsinhalte von AP1, die für alle IT-Berufe identisch sind. Durch die Clusterung der Themen nach Häufigkeit und Punktvergabe ermögliche ich einen Überblick darüber, welche Themen in der Vergangenheit am häufigsten abgefragt wurden und welche besonders wertvoll für deine Vorbereitung sind. Hierbei stelle ich fest, dass Themen wie Hardware und Wirtschaftlichkeit konstant präsent waren, sodass eine gezielte Vorbereitung in diesen Bereichen besonders empfehlenswert ist.
Im Anschluss gehe ich speziell auf die AP2-Prüfungen für Anwendungsentwickler:innen ein. Durch die detaillierte Auswertung aller Aufgaben aus den Prüfungen hat sich herausgestellt, dass Pseudocode mit Abstand die meisten Punkte einbringt. Diese Erkenntnis ist besonders wertvoll für alle Prüflinge, die häufig Schwierigkeiten in diesem Bereich haben. Des Weiteren betrachte ich die Themen Datenbanken und Algorithmen, die ebenfalls häufig abgefragt werden, und gebe Tipps, wie man sich strukturiert auf diese Inhalte vorbereiten kann.
Zusätzlich biete ich den Zuhörer:innen die Möglichkeit, die aufbereiteten Statistiken direkt auf meiner Website einzusehen. Dort sind nicht nur die häufigsten Themen gelistet, sondern auch spezifische Aufgaben, die als besonders punkteträchtig identifiziert wurden. Ich ermutige alle Zuhörer:innen dazu, sich intensiv mit diesen Materialien auseinanderzusetzen und ihre Prüfungsstrategien entsprechend anzupassen.
Gemeinsam erarbeiten wir Ansätze, wie man das Lernen optimieren kann, um mit den erlangten Erkenntnissen in die prüfungsrelevanten Themen gezielt einzutauchen. Ich teile auch persönliche Empfehlungen zu Literaturempfehlungen und Vorbereitungsstrategien, die sich in der Praxis bewährt haben. Mein Ziel ist es, dir nicht nur die notwendigen Informationen an die Hand zu geben, sondern auch eine strukturierte Herangehensweise an die Prüfungsvorbereitung zu vermitteln.
Die Episode ist also nicht nur eine Auflistung von Themen, sondern bietet eine tiefere Einsicht in die Prüfungsdynamik der IHK und geht auf die richtige strategische Vorbereitung ein. Sei es als Auszubildender oder als Ausbilder, die gewonnenen Daten sind ein wertvolles Werkzeug zur Verbesserung der Prüflingsleistung. Damit möchte ich dich motivieren, deine Vorbereitung aktiv mit diesen Daten zu unterstützen, um deine Erfolgschancen signifikant zu erhöhen.
Literaturempfehlungen
Ich habe meine Literaturempfehlungen extra für diese Episode komplett aktualisiert: Literaturempfehlungen für die IT-Berufe.
Links

* Permalink zu dieser Podcast-Episode
* RSS-Feed des Podcasts
* Themen der schriftlichen IHK-Prüfungen der IT-Berufe

Um die Änderungen im Prüfungskatalog für die AP2 als Fachinformatiker Anwendungsentwicklung ab 2025 geht es in der einhunderteinundneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt
Zur AP2 (Gestreckte Abschlussprüfung Teil 2) als Fachinformatiker Anwendungsentwicklung im Sommer 2025 gilt ein neuer Prüfungskatalog. Ich habe die Unterschiede zusammengestellt.
Zusammenfassung
Die folgenden Punkte fassen die zentralen Änderungen (aus meiner Sicht) zusammen.
Zusätzliche bzw. genauer spezifizierte Inhalte

* Anomalien/Redundanzen in Datenbanken erkennen
* SQL (detailliertes Beiblatt)
* Last-/Performancetests
* potentielle Angriffe wie Man-in-the-Middle, SQL-Injection, DDoS-Attacke
* Kerberos
* ODBC
* Monitoring von Systemen
* Programm- und Konfigurationsdokumentation
* NAS und SAN
* Softwarequalitätsmerkmale
* Cyber-physische Systeme
* Test Driven Development (TDD)
* Scrum
* Architektur-Pattern
* Kapselung in der Objektorientierung
* Sortierverfahren wie Bubble/Selection/Insertion Sort

Gestrichene Inhalte

* „Trends“ wie Smart Grid, IoT, Industrie 4.0, KI, Blockchain, Big Data, Augmented Reality
* Struktogramm (Nassi-Shneiderman) und Programmablaufplan (PAP)
* Load Balancing
* Data Warehouse
* Programmierparadigmen

Detaillierter Vergleich der bisherigen und neuen Inhalte des Prüfungskatalogs für die AP2 als Fachinformatiker Anwendungsentwicklung
In der folgenden Tabelle habe ich alle Unterschiede zwischen altem (ab 2020) und neuem (ab 2025) Prüfungskatalog für die AP2 als Fachinformatiker Anwendungsentwicklung gegenübergestellt.

* Rote Punkte habe ich im neuen Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen so nicht mehr erwartet.
* Grüne Punkte habe ich im alten Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen zusätzlich erwartet.
* Wenn sich lediglich Formulierungen oder Aufteilungen geändert haben, aber die Punkte inhaltlich gleich geblieben sind, stehen sie gar nicht in der Tabelle.
* Wenn Punkte an andere Stellen im Prüfungskatalog verschoben wurden, habe ich das in den Spalten Alter Unterpunkt und Neuer Unterpunkt gekennzeichnet.
* Meine persönliche (!) Bewertung (hin und wieder leicht ironisch) der Änderungen stehen in der Spalte Kommentar.
* Ein „x“ in Spalte wichtig deutet auf eine zentrale Änderung hin, die sich meiner Meinung nach merklich auf die Prüfungsvorbereitung der Azubis auswirkt.
* Die Punkte haben Präfixe, weil sie sich sonst doppeln. FÜ steht für Fachrichtungsübergreifende berufsprofilgebende Fertigkeiten, Kenntnisse und Fähigkeiten und BP für Berufsprofilgebende Fertigkeiten, Kenntnisse und Fähigkeiten in der Fachrichtung Anwendungsentwicklung.





Unterpunkt


Alter Inhalt


Neuer Inhalt


Alter Unterpunkt


Neuer Unterpunkt


Kommentar


wichtig






FÜ-01.02




BGB/HGB














Chancen und Risiken der technischen Entwicklungen kennen und identifizieren können




FÜ-02.01




die „Trends“ von gestern sind der Normalzustand heute








Ausfallsicherheit, bspw. redundante Systeme,

Um die Änderungen im Prüfungskatalog für die AP1 der IT-Berufe ab 2025 geht es in der einhundertneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt
Zur AP1 (Gestreckte Abschlussprüfung Teil 1) der IT-Berufe im Frühjahr 2025 gilt ein neuer Prüfungskatalog. Ich habe die Unterschiede zusammengestellt.
Zusammenfassung
Die folgenden Punkte fassen die zentralen Änderungen (aus meiner Sicht) zusammen.
Zusätzliche bzw. genauer spezifizierte Inhalte

* Projekte

* Projektmerkmale
* SMART-Prinzip
* Wirtschaftlichkeit
* Wasserfallmodell und Scrum


* Künstliche Intelligenz (KI)
* Software

* Softwareprodukte wie ERP, SCM, CRM
* Social Media
* Barrierefreiheit auf Websites


* Netzwerkadministration

* Einbindung eines PCs in eine Domäne
* IPv4 und IPv6


* HDD vs. SSD
* Übertragungsraten, -zeiten und Datenmengen berechnen
* UML-Aktivitätsdiagramm
* Fehler in Code finden und Schreibtischtest durchführen
* IT-Sicherheit

* Schutzziele (Vertraulichkeit, Verfügbarkeit, Integrität)
* Hashverfahren
* Zweifaktorauthentifizierung (2FA)
* Härtung von Betriebssystemen


* Datenschutz

* Betroffenenrechte nach DSGVO
* Anonymisierung und Pseudonymisierung



Gestrichene Inhalte

* Projekte

* Weitere Vorgehensmodelle außer Wasserfall und Scrum
* SWOT-Analyse (Stärken/Schwächen)


* Hardware

* SAN
* RAID


* LTE und 5G
* Programmierung

* Vererbung in der Objektorientierung
* Struktogramm (Nassi-Shneiderman) und Programmablaufplan
* Softwarequalitätskriterien


* Datenbanken

* Alle nicht-relationalen Datenbanken
* SQL


* ISO-Normen wie die 2700x
* Dokumentationen

Detaillierter Vergleich der bisherigen und neuen Inhalte des Prüfungskatalogs für die AP1 der IT-Berufe
In der folgenden Tabelle habe ich alle Unterschiede zwischen altem (ab 2020) und neuem (ab 2025) Prüfungskatalog für die AP1 der IT-Berufe gegenübergestellt.

* Rote Punkte habe ich im neuen Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen nicht mehr erwartet.
* Grüne Punkte habe ich im alten Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen zusätzlich erwartet.
* Wenn sich lediglich Formulierungen oder Aufteilungen geändert haben, aber die Punkte inhaltlich gleich geblieben sind, stehen sie gar nicht in der Tabelle.
* Wenn Punkte an andere Stellen im Prüfungskatalog verschoben wurden, habe ich das in den Spalten Alter Unterpunkt und Neuer Unterpunkt gekennzeichnet.
* Meine persönliche (!) Bewertung (hin und wieder leicht ironisch) der Änderungen stehen in der Spalte Kommentar.
* Ein „x“ in Spalte wichtig deutet auf eine zentrale Änderung hin, die sich meiner Meinung nach merklich auf die Prüfungsvorbereitung der Azubis auswirkt.





Unterpunkt


Alter Inhalt


Neuer Inhalt


Alter Unterpunkt


Neuer Unterpunkt


Kommentar


wichtig






01.01




Merkmale eines Projektes






war vorher tatsächlich nicht explizit genannt






01.01




SMART-Prinzip

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

Inhalt
Kurzübersicht Lastenheft

* Definition laut DIN 69901-5: „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.
* Verfasst von: Auftraggeber, also aus Sicht des Kunden.
* Inhalt: Lösungsneutrale funktionale und nicht-funktionale Anforderungen an ein Produkt, eine zu erstellende Software oder ein Projektergebnis aus Sicht des Auftraggebers.
* Fragen: WAS soll erreicht werden? WARUM ist das wichtig? WOFÜR wird das benötigt? WER will das haben?
* Ziel: Basis, um Angebote von potenziellen Auftragnehmern einzuholen. Es bildet die Grundlage für das vom Auftragnehmer zu erstellende Pflichtenheft.
* Rechtliche Relevanz: keine
* Mögliche Inhalte

* Anforderungen der Stakeholder (z.B. Fachlichkeit, Regualatorik, Usability, Performance, Hardware-/Netwerk-/Softwareumgebung)
* Ist-Zustand und Soll-Zustand
* Abnahmekriterien für die Prüfung, ob die Anforderungen erfüllt sind
* Einschränkungen bei zu verwendenden Technologien
* Anforderungen an den Auftragnehmer (z.B. Zertifizierung)
* Schnittstellen
* Sonstige Anforderungen (z.B. Dauer, Kosten, Meilensteine)



Kurzübersicht Pflichtenheft

* Definition laut DIN 69901-5: „vom Auftragnehmer erarbeitete[n] Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“.
* Verfasst von: Auftragnehmer, also aus Sicht des Dienstleisters.
* Inhalt: Vorschlag für technische Lösung der Anforderungen aus dem Lastenheft.
* Fragen: WIE sollen die Anforderungen umgesetzt werden? WELCHE Technologien kommen zum Einsatz?
* Ziel: Konkretes Angebot eines Auftragnehmers, um die Anforderungen aus dem Lastenheft des Auftraggebers zu erfüllen. Basis für die Kalkulation von Kosten/Aufwänden und das Erstellen eines Angebots. Definiert die Vorgaben für die spätere Implementierung.
* Rechtliche Relevanz: wird Vertragsbestandteil und dient zur Abnahme der erbrachten Leistung
* Mögliche Inhalte

* Spezifikationen des geplanten Ergebnisses bzw. die technische Realisierung, z.B. Architektur, Technologien, UML-Diagramme, ER-Modelle, geplante Prozessabläufe, UI-Entwürfe
* Entwicklungsprozess, Projektplan mit Meilensteinen, Vorgaben zur Kommunikation
* Ressourcen wie konkrete Personen, Subunternehmen, Technologien



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

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

Pflichtenheft

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

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

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

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

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

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

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

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

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

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

Wie sieht richtig gute Teamarbeit in der Softwareentwicklung aus?

* Kommunikation ist das A und O, z.B. wenn ein Feature fertig ist, damit die Kolleg:innen darauf aufsetzen können
* alle Teammitglieder:innen sollten auch aktiv Hilfe anbieten und einfordern
* die gesamte Softwareentwicklung ist Teamarbeit und die geht schon mit der Produktidee los
* dabei kann es helfen, verschiedene Perspektiven einzunehmen, um ein besseres Bild der Anforderungen zu bekommen
* auch weitere Aufgaben lassen sich besser im Team lösen: Risiken abschätzen, Prioritäten ableiten, Product Backlog füllen
* wenn das Verhältnis von Kosten und Nutzen passt, startet die Implementierung und Aufgaben werden im Team verteilt
* in Christians Team werden Konzepte z.B.

Um Datenbanktransaktionen, die ACID-Prinzipien und Alternativen dazu geht es in der einhundertsiebenundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt
Datenbanktransaktionen sollten jedem/jeder ITler:in etwas sagen, da wir fast täglich mit datenbankgestützten Anwendungen arbeiten, egal, ob wir selbst diese Anwendungen programmieren oder „nur“ Abfragen gegen eine Datenbank durchführen.
Was ist eine Datenbanktransaktion?
Eine Transaktion ist eine Menge aus mehreren zusammenhängenden Datenbankoperationen, die gemeinsam als eine Einheit durchgeführt werden müssen.
Beispiele für Datenbanktransaktionen:

* Banküberweisung von 100 EUR von Konto DE123 auf Konto DE432

* UPDATE konto SET kontostand = kontostand - 100 WHERE iban = 'DE123';
* UPDATE konto SET kontostand = kontostand + 100 WHERE iban = 'DE432';


* Neuen Tag katze zu einem Blog-Post mit ID 123 hinzufügen

* INSERT INTO tag (id, name) VALUES (1, 'katze');
* INSERT INTO tag_post (post_id, tag_id) VALUES (123, 1);


* Neue Bestellung für einen Kunden mit ID 324 erfassen für Artikel 253

* INSERT INTO bestellung (id, datum, kunde_id) VALUES (123, '2024-04-10', 324);
* INSERT INTO bestellposition (bestellung_id, artikel_id, menge, preis) VALUES (123, 253, 1, 123.92);


* Neuen Tarifsatz einer Versicherung anlegen und bisherigen beenden

* UPDATE tarif SET gueltig_bis='2024-04-10' WHERE id=122;
* INSERT INTO tarif (id, gueltig_ab, beitrag) VALUES (123, '2024-04-10', 143.23);



Begriffsabgrenzung
Eine Datenbanktransaktion ist nicht zu verwechseln mit einer Transaktion im Geschäftsbetrieb, z.B. einer Überweisung bei einer Bank, dem Kauf eines Autos oder der Buchung eines Fluges.
Die ACID-Prinzipien
Datenbanktransaktion müssen/sollen bestimmten Kriterien genügen, die als ACID-Prinzipien bekannt sind.

* Atomarität/Atomicity: Alle Datenbankoperationen werden entweder vollständig gemeinsam durchgeführt oder gar nicht. Es kann nicht sein, dass nur einige Operationen durchgeführt werden und andere nicht. Dazu werden die Datenbankoperationen in eine Transaktion „eingeklammert“.

* Beispiel: Bei der Banküberweisung darf nicht nur Geld abgebucht oder gutgeschrieben werden, sondern beide Buchungen müssen gemeinsam durchgeführt werden.


* Konsistenz/Consistency: Wenn die Datenbank vor der Transaktion in einem konsistenten Zustand war, dann muss sie es auch nach der Transaktion sein.

* Beispiel: Bei der Banküberweisung bleibt der Gesamtbetrag an Geld gleich. Es entsteht kein Geld aus dem Nichts und es geht auch kein Geld verloren.


* Isolation/Isolation: Mehrere Transaktionen dürfen sich nicht gegenseitig beeinflussen. Hierzu folgen weiter unten verschiedene Maßnahmen zur Umsetzung.

* Beispiel: Bei zwei parallelen Banküberweisungen vom gleichen Konto müssen beide Beträge nacheinander abgebucht werden und nicht nur der der zuletzt durchgeführten Transaktion.


* Dauerhaftigkeit/Durability: Die Daten müssen nach Abschluss der Transaktion persistent gespeichert sein und z.B. auch einen Systemausfall überstehen. Das wird durch sogenannte Transaktionslogs sichergestellt.

* Beispiel: Wenn nach dem Abschluss einer Transaktion der Datenbankprozess abstürzt, müssen auch nach dem Neustart der Datenbank die aktualisierten Daten vorhanden sein.



Maßnahmen zur Wahrung der Isolation von Transaktionen
Wenn Transaktionen nicht isoliert voneinander ablaufen, können verschiedene Probleme in der Datenbank auftreten.

* Dirty Read: Veränderte Daten einer noch offenen Transaktion werden von einer anderen Transaktion gelesen und weisen somit einen „dreckigen“ Zustand auf,

Um die angemessene fachliche bzw. technische Tiefe des Themas für das IHK-Abschlussprojekt für Anwendungsentwickler:innen geht es in der einhundertsechsundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt
Viele Projektanträge zum Abschlussprojekt werden abgelehnt, weil das umzusetzende Projekt nicht die nötige fachliche bzw. technische Tiefe aufweist. In unserem Prüfungssystem gibt es dafür sogar einen expliziten Ablehnungsgrund. Doch was heißt es genau, dass die fachliche Tiefe nicht erreicht wurde? Welche fachliche Tiefe ist überhaupt angemessen und wie erkenne ich als Prüfling, ob ich sie erreiche?
Mein Standardbeispiel: Projektverwaltung
Ich führe als Beispiel für eine übliche Projektarbeit für Anwendungsentwickler:innen immer eine klassische Web-Anwendung an. Nehmen wir das oft strapazierte Beispiel einer Zeiterfassungssoftware oder einer Projektverwaltung. Dabei handelt es sich um eine kleine Web-Anwendung mit ein paar Datenbanktabellen, etwas fachlicher Logik und ein paar netten Oberflächen.
In solch einer Anwendung kann ich als Anwendungsentwickler:in alles zeigen, was ich in meiner dreijährigen Ausbildung gelernt haben sollte. Soll ich ein Projekt enpfehlen, führe ich deswegen gerne dieses Beispiel für ein fachlich ausreichendes Projekt für die Abschlussprüfung an.

* Ich kann eine Datenbank modellieren, z.B. mit einem ERM oder Tabellenmodell.
* Ich kann ein Klassendesign entwerfen, z.B. mit einem Klassendiagramm oder gar mit Test Driven Development.
* Ich kann die Oberflächen gestalten, natürlich nach ergonomischen Gesichtspunkten und mit Mockups für den ersten Entwurf.
* Außerdem muss ich mich um das Zusammenspiel der Komponenten kümmern und brauche dafür eine tragfähige Architektur, z.B. MVC.

Kurz gesagt ist in solch einem Projekt alles Technische enthalten, was man heutzutage in der Programmierung können muss. Und ich kann mich vieler Methoden der Softwareentwicklung bedienen, die mein planvolles Vorgehen dokumentieren.
Hast du auch ein paar konkrete Zahlen?
Als ganz grobe Daumenregel für Anwendungsentwickler:innen führe ich immer ein „klassisches“ Webprojekt an: kleine Datenbank, ein bisschen Logik, Frontend drüber. Da kann man das volle Spektrum der Entwicklungstätigkeiten zeigen.

* ca. fünf Datenbanktabellen („eine Hand voll“)
* ca. fünf Oberflächen dazu
* ca. zehn Klassen (tendenziell eher mehr)

Sollte die Anwendung eine komplizierte Logik umsetzen, kann natürlich bei den anderen Komponenten entsprechend gekürzt werden. Diese grobe Richtlinie ist sicherlich nicht allgemeinverbindlich. Es kommt immer auf den Einzelfall an. Ich möchte nur deutlich machen, dass eine triviale Konsolenapplikation, die eine Textdatei einliest und wieder speichert, nicht ausreicht. Es sei denn, die Applikation verwendet dafür einen selbst programmierten Verschlüsselungsalgorithmus. 😉
Die Diagramme aus dem Titelbild dieser Episode sollten offensichtlich zeigen, dass dieser Umfang für ein Abschlussprojekt nicht ausreicht! 😂 Aber ich habe schon Artefakte in echten Dokus gesehen, die nicht viel umfangreicher waren (z.B. nur zwei Use-Cases oder drei Aktivitäten).
Brauche ich alle Komponenten – Datenbank, Logik, UI?
Das heißt nicht, dass jedes Abschlussprojekt alle genannten Komponenten umfassen muss. Nicht alle Unternehmen haben die Anforderung, Weboberflächen über Datenbanken zu gestalten. In vielen Betrieben wird eine bestehende Software erweitert, eine Oberfläche angepasst, oder eine Datenbank um zusätzliche Tabellen erweitert. Oft werden auch Programme benötigt, die gar keine grafische Oberfläche haben. Wenn es z.B. um den Datenabgleich zwischen ERP-System und Webshop geht, der nachts als Batchjob laufen soll, ist es völlig unnötig, eine schön gestaltete grafische Oberfläche dazu zu entwickeln. Auch werden inzwischen oft REST-APIs als Abschl...

Um den sinnvollen Aufbau eines IHK-Abschlussprojekts für Fachinformatiker:innen Anwendungsentwicklung geht es in der einhundertfünfundachzigsten Episode des IT-Berufe-Podcasts.

Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung
Oft lese ich Projektdokumentationen für den Beruf Fachinformatiker:in Anwendungsentwicklung, die in sich einfach nicht stimmig sind. Der Projektablauf folgt keinem roten Faden und Artefakte werden wild durcheinandergewürfelt. Oft werden auch einfach nur Kapitel aus Dokumentationsvorlagen „ausgefüllt“, scheinbar ohne über ihre Sinnhaftigkeit nachzudenken.
In dieser Podcast-Episode gebe ich einen Überblick über einen – aus meiner Sicht – sinnvollen Ablauf eines IHK-Projekts im Bereich Anwendungsentwicklung inkl. möglicher Artefakte und ihrem Zweck. Dabei gehe ich nicht auf die Beschreibung des Projekts, die Wirtschaftlichkeitsbetrachtung, das Projektmanagement, die Ressourcenplanung usw. ein, sondern nur auf die Planung und Durchführung der eigentlichen Aufgabe: der Entwicklung einer Softwarelösung. Selbstverständlich gehören aber alle genannten Punkte auch in eine IHK-Projektdokumentation.
Wahl des Vorgehensmodells
Fast immer ist das Wasserfallmodell das einzig sinnvolle Vorgehensmodell, da das IHK-Projekt vom Prüfling alleine in einer fest vorgegebenen Zeit mit vorgegebenem (weil im Antrag genehmigten) Umfang umgesetzt werden muss.
Praxisbeispiele für unpassende Prozesse:

* Scrum gewählt, aber

* klassische Wasserfallphasen durchgeführt/beschrieben
* Lasten-/Pflichtenheft erstellt statt User Stories
* Projekt alleine umgesetzt ohne Team/Scrum Master/Product Owner
* gesamtes Projekt ist ein einziger Sprint


* XP gewählt, aber

* keine Praktiken (z.B. Pair Programming, Test Driven Development) angewendet


* Kanban gewählt, aber

* Lanes nur ToDo/Doing/Done



Artefakte methodisch sinnvoll einsetzen

* Software soll nicht einfach „runterprogrammiert“ werden, sondern methodisch entwickelt werden. Dabei helfen verschiedene Artefakte wie Entity-Relationship-Modelle, UML-Diagramme usw.
* Diagramme können oft auf zwei Arten eingesetzt werden: zur Modellierung (vor der Implementierung) und zur Dokumentation (nach der Implementierung). Sie haben keinen Selbstzweck, sondern sollen immer den jeweiligen Prozessschritt unterstützen.
* Ihr Einsatz muss zum gewählten Prozess passen. Ein Klassendiagramm zur Modellierung passt z.B. nicht so gut zu Test-Driven-Development, bei dem die Klassen sich erst bei der Implementierung ergeben.
* Die Artefakte müssen auch zeitlich sinnvoll im Projekt untergebracht werden. Die Anforderungen erst nach der Implementierung zu dokumentieren ist sinnfrei.
* Artefakte sollen im Prozess auch einen erkennbaren Mehrwert für die späteren Prozessschritte bieten. Mockups sind z.B. sehr hilfreich, um auf ihrer Basis ein Datenmodell zu erzeugen. Und auf Basis des Datenmodells können dann wiederum Klassen modelliert werden usw.
* Durch den passenden Einsatz der Artefakte in den jeweiligen Prozessschritten füllt sich die Projektdokumentation automatisch mit spannenden Inhalten für die Prüfer:innen! 😀

Anforderungen aufnehmen

* Ist-Analyse durchführen

* Bisherige Lösung untersuchen, Schwachstellen aufdecken.
* mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN, Screenshots/Fotos der bisherigen Lösung


* Anforderungen an neue Lösung strukturiert erfassen

* Interviews mit Stakeholdern führen
* Priorisierung der Anforderungen
* Ergebnis: z.B. User Stories, MoSCoW


* Anwendungsfälle modellieren

* Was wollen die Stakeholder mit der Anwendung fachlich machen/erreichen?
* Ergebnis: Use-Case-Diagramm

Um alles rund um Verträge als Vorbereitung auf die AP1 geht es in der einhundertvierundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt
Für die AP1 ist es sinnvoll, einige grundsätzliche Vertragsarten zu kennen und unterscheiden zu können. Sowohl auf Anbieter- als auch auf Nachfragerseite ist es wichtig zu verstehen, welche Art von Vertrag vorliegt, da daraus unterschiedliche Rechte und Pflichten entstehen können.
Disclaimer: Das hier ist keine Rechtsberatung! 🙂
Vertrag
Ein Vertrag ist die von zwei (oder mehr) Vertragsparteien erklärte Einigung über die Begründung eines Schuldverhältnisses (siehe § 311 BGB). Hierfür sind zwei übereinstimmende Willenserklärungen erforderlich. Beispiel: Angebot und Annahme, Bestellung und Lieferung.
Verträge können schriftlich, mündlich oder durch „konkludentes Handeln“ entstehen.
Vertragsarten

* Kaufvertrag: Verkäufer:in verkauft etwas an Käufer:in.

* Beispiele in der IT: Hardware-/Softwarekauf


* Lizenzvertrag: Lizenzgeber:in räumt Lizenznehmer:in Rechte an einem geschützten Werk (z.B. Patent, Marke, Urheberrecht) ein.

* Beispiele in der IT: Lizenzierung von Software, Bildrechte einkaufen


* Servicevertrag: Regelt die Erbringung produktbezogener Leistungen zwischen Anbieter:in und Kund:in.

* Beispiele in der IT: Wartungsverträge für Software (z.B. für Patches und Updates) oder Hardware durch Dienstleister


* Mietvertrag: Vermieter:in überlässt Mieter:in eine bewegliche oder unbewegliche Sache zur zeitweisen Nutzung.

* Beispiele in der IT: Miete eines Autos für eine Dienstreise, Miete von Software


* Leasingvertrag: Leasinggeber:in (Vermieter:in) überlässt Leasingnehmer:in (Mieter:in) eine Sache zur Nutzung wie bei der Miete, aber mit Fokus auf eine langfristige Nutzung mit der Möglichkeit des Erwerbs am Ende der Vertragslaufzeit. Außerdem sind bestimmte Sachverhalte anders geregelt, z.B. die Inspektion beim geleasten Auto oder die Wahl des konkreten Modells und der Ausstattung durch den/die Leasingnehmer:in.

* Beispiele in der IT: Leasing teurer Hardware statt einmaligen Kaufs


* Werkvertrag: Unternehmer:in (Auftragnehmer:in) verpflichtet sich zur Herstellung eines bestimmten Werks für den/die Auftraggeber:in (Besteller:in). Hier muss das Endergebnis klar definiert sein („Werk“).

* Beispiele in der IT: Programmierung einer kompletten Individualsoftware für eine Kundin


* Dienstvertrag: Schuldner:in verpflichtet sich zur Leistung eines Dienstes an den/die Gläubiger:in. Hierbei steht die Dienstleistung an sich im Vordergrund und nicht das Endergebnis.

* Beispiele in der IT: Programmierung für einen Kunden auf Basis von Tagessätzen


* Fernabsatzvertrag: Bei Verträgen, die über Fernkommunikationsmittel (Internet, Telefon usw.) geschlossen werden, haben Verbraucher:innen besondere Rechte, insb. ein Widerrufsrecht.
* Arbeitsvertrag: Definiert die Rechte und Pflichten von Arbeitgeber:in und Arbeitnehmer:in.

Vertragsbestandteile
z.B. Leistungsbeschreibung, Termine/Fristen, fällige Entgelte, Lasten- und Pflichtenheft (insb. bei Softwareerstellung), Konventionalstrafen, Haftung
Allgemeine Geschäftsbedingungen (AGB)
Mit AGBs regeln Unternehmen ihre grundsätzliche Vertragsgestaltung, also Inhalte, die für alle Verträge gelten.
Beispielinhalte:

* Informationen zum Vertragsschluss (z.B. Telefon, E-Mail), Bestätigungen usw.
* Zahlungsbedingungen (z.B. Fristen, Zahlungsmöglichkeiten)
* Eigentumsvorbehalt
* Lieferungskonditionen und -möglichkeiten
* übliche Geschäftszeiten
* Gewährleistung/Garantie
* Haftung

Service-Level-Agreement (SLA)
Ein SLA legt fest,

Um Softwarequalität nach ISO 9126 geht es in der einhundertdreiundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt
Definition von Qualität

Qualität ist der Grad der Übereinstimmung mit den Anforderungen.

Da verschiedene Stakeholder unterschiedliche Anforderungen an unser Projekt haben, ist die Qualität recht subjektiv. Alle Stakeholder zu 100% zufrieden zu stellen, wird in einem echten Projekt wohl nicht möglich sein.
Maßnahmen zur Qualitätssicherung
Die Softwarequalität kann mit verschiedenen konkreten Maßnahmen während der Entwicklung sichergestellt werden. Diese nicht vollständige Liste enthält einige Maßnahmen, die Prüflinge auch in ihrem eigenen Abschlussprojekt anwenden können.

* Audits
* Code Reviews
* Testmethoden
* Entwicklungsprozess
* Dokumentation
* Statische Codeanalyse
* Pair Programming
* Bugtracking
* Continuous Integration/Delivery/Deployment

Softwarequalität nach ISO 9126

* Funktionalität

* Angemessenheit
* Interoperabilität
* Ordnungsmäßigkeit
* Richtigkeit
* Sicherheit


* Änderbarkeit

* Analysierbarkeit
* Modifizierbarkeit
* Testbarkeit
* Stabilität


* Übertragbarkeit

* Anpassbarkeit
* Austauschbarkeit
* Installierbarkeit
* Koexistenz


* Effizienz

* Verbrauchsverhalten
* Zeitverhalten


* Zuverlässigkeit

* Fehlertoleranz
* Reife
* Wiederherstellbarkeit


* Benutzbarkeit

* Attraktivität
* Bedienbarkeit
* Erlernbarkeit
* Verständlichkeit



Literaturempfehlungen
Hier gibt es diese Podcast-Episode noch einmal als Video bei YouTube:

Links

* Permalink zu dieser Podcast-Episode
* RSS-Feed des Podcasts
* Video zur Podcast-Episode bei YouTube
* ISO/IEC 9126 in der Wikipedia

Um Eigenschaften und Unterscheidungsmerkmale von Programmiersprachen geht es in der einhundertzweiundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt
Was ist eine Programmiersprache?

* Programmiersprache: „Eine Programmiersprache ist eine formale Sprache zur Formulierung von Datenstrukturen und Algorithmen, d.h. von Rechenvorschriften, die von einem Computer ausgeführt werden können.“ [Herv. d. Verf.]
* Bausteine von Algorithmen: Sequenz, Verzweigung (z.B. if, switch, aber auch Pattern Matching), Wiederholung (GOTO, Schleifen, Rekursion)
* Turing-complete: „[…] die Eigenschaft einer Programmiersprache oder eines anderen logischen Systems, sämtliche Funktionen berechnen zu können, die eine universelle Turingmaschine berechnen kann.“

Demnach sind keine Programmiersprachen: HTML/XML (Auszeichnungssprache), CSS (Stylesheet-Sprache), SQL (Datenbankabfragesprache).
Sprache vs. Plattform vs. Ökosystem
Programmiersprachen bringen meistens „eingebaute“ („native“) Funktionen mit, die direkt in der Syntax der Sprache formuliert werden können:

* Ein-/Ausgabe-Befehle, um Daten verarbeiten zu können
* Deklaration von Variablen zum Speichern von Informationen
* mathematische Funktionen wie Addition, Multiplikation usw.
* Steueranweisungen für Verzweigung und Wiederholung
* Möglichkeiten zur Programmunterteilung (z.B. Funktionen, Subprogramme)
* Einbinden von (externen) Bibliotheken zur Wiederverwendung

Viele Programmiersprachen bringen außerdem noch eine umfangreiche Bibliothek an vorgefertigten Implementierungen (z.B. in Form von Klassen in objektorientierten Sprachen) mit. Diese Bibliothek ist bei der Einarbeitung in eine neue Sprache meist schwieriger/langwieriger zu lernen als die Syntax. Oftmals teilen sich mehrere Programmiersprachen die Bibliotheken einer gemeinsamen Plattform, z.B. der JVM bei Java und Kotlin bzw. .NET bei C# und Visual Basic.
Darüber hinaus existiert meist auch noch ein ganzes Ökosystem rund um die Sprache/Plattform:

* Build-Tools, z.B. Maven, Gradle
* Dependency-Management, z.B. NPM, RubyGems
* Test-Frameworks, z.B. JUnit
* weitere Frameworks und Libraries, z.B. Spring, Show more...