IT-Berufe-Podcast

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

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

Lastenheft

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

Pflichtenheft

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

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

Lastenheft

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

Pflichtenheft

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

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.

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.

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.

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.

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).

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.

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.

*

Der Beitrag Lastenheft und Pflichtenheft – IT-Berufe-Podcast #189 erschien zuerst auf IT-Berufe-Podcast.

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

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

Der Beitrag Teamarbeit bei der Softwareentwicklung mit Christian Kranert – IT-Berufe-Podcast #188 erschien zuerst auf IT-Berufe-Podcast.

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

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.

Eine Transaktion ist eine Menge aus mehreren zusammenhängenden Datenbankoperationen, die gemeinsam als eine Einheit durchgeführt werden müssen.

Beispiele für Datenbanktransaktionen:

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.

Datenbanktransaktion müssen/sollen bestimmten Kriterien genügen, die als ACID-Prinzipien bekannt sind.

Wenn Transaktionen nicht isoliert voneinander ablaufen, können verschiedene Probleme in der Datenbank auftreten.

Die Datenbank kann verschiedene Transaktionsisolationsebenen implementieren, um den obigen Problemen entgegenzuwirken. Grundsätzlich werden dabei Sperren verwendet, um die gleichzeitige Verarbeitung der Daten einzuschränken. Es kann dabei eine Lesesperre und/oder eine Schreibsperre gesetzt werden, wodurch das gleichzeitige Lesen bzw. Schreiben eingeschränkt wird.

Mit der Transaction Control Language (TCL) gibt es eine eigene Familie an SQL-Befehlen, die sich nur um die Transaktionssteuerung kümmert. Hiermit können Datenbankoperationen zu einer Transaktion zusammengefasst werden.

In vielen Datenbanken muss man nicht explizit Transaktionen starten und beenden. Sie verwenden ein sogenanntes Auto-Commit. Dabei wird jedes Statement in einer eigenen Transaktion durchgeführt.

Brauche ich als Softwareentwickler:in überhaupt Wissen über Datenbanktransaktionen? In modernen Entwicklungsprojekten werden doch sowieso objektrelationale Mapper (ORM) verwendet. Doch auch diese ORMs können natürlich nicht zaubern, sondern verwenden unter der Haube die normalen Datenbankoperationen. Daher ist auch bei Verwendung eines ORMs wichtig zu wissen, welche Operationen in einer gemeinsamen Transaktion durchgeführt werden müssen.

Dafür bieten viele ORMs entsprechende Befehle an. Jakarta EE hat sogar einen eigenen Standard dafür: Jakarta Transactions (JTA). Dort wird z.B. Annotation @Transactional verwendet. Diese wird an eine Java-Methode geschrieben, die dann automatisch innerhalb einer Datenbanktransaktion ausgeführt wird. Im Fall einer aufgetretenen Exception wird dabei dann automatisch ein Rollback durchgeführt.

Transaktionen nach den ACID-Prinzipien sind ein wichtiger Bestandteil vieler Datenbanksysteme. Sobald die Datenbank jedoch auf mehrere Knoten verteilt wird, können Transaktionen zu einem Problem werden. Das sogenannte CAP-Theorem besagt, dass es in einem verteilten System nicht möglich ist, alle drei Eigenschaften Konsistenz, Verfügbarkeit und Ausfalltoleranz gleichzeitig zu garantieren.

Angenommen, die verteilte Datenbank soll zu jedem Zeitpunkt in einem konsistenten Zustand sein (also alle Informationen auf allen Knoten sollen identisch sein), dann führt ein Ausfall eines Knoten automatisch dazu, dass eine Transaktion fehlschlagen muss, da der ausgefallene Knoten nicht sofort aktualisiert werden kann. Die Konsistenz wäre dann zwar gewährleistet, aber die Partitionstoleranz nicht.

Da heutzutage viele Anwendungen tatsächlich mit verteilten Datenbanken arbeiten, wurde mit BASE ein Gegenentwurf zu ACID geschaffen. Das Wort ist etwas konstruiert, um das Gegenstück zu ACID zu bilden. Aus der Chemie kennen wir den Unterschied zwischen Säure („acid“) und Lauge („base“). Im Kern stellt ACID die Konsistenz eines Systems sicher, während BASE die Verfügbarkeit in den Vordergrund stellt.

*

In Kapitel 13 gibt es eine gute und kurze Einführung in das Thema Datenbanken inkl. Transaktionen. Ich habe das Kapitel auch schon im Buchclub besprochen: Buchclub: Handbuch für Fachinformatiker (Teil 11: Datenbanken)

Der Beitrag Datenbanktransaktionen, ACID, CAP-Theorem und BASE – IT-Berufe-Podcast #187 erschien zuerst auf IT-Berufe-Podcast.

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.

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?

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.

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.

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.

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).

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 Abschlussprojekt erstellt, die natürlich auch nicht von Menschen bedient werden. Daher ist es völlig legitim, auf die ein oder andere Komponente im Abschlussprojekt zu verzichten.

Auch heißt es umgekehrt nicht automatisch, dass man ein fachlich ausreichendes Projekt hat, nur weil alle Schichten Berücksichtigung finden. Eine Weboberfläche mit einem Formular, die simple CRUD-Operationen gegen eine Datenbanktabelle durchführt, ist selbstverständlich nicht umfangreich genug.

Dieses Problem haben meiner Erfahrung nach oftmals die Anwendungsentwickler:innen im SAP-Umfeld. Hier wird häufig nur sehr wenig tatsächlicher Code produziert, sondern viel mehr Zeit für die hochkomplexe Infrastruktur verbraten. Da gehen allein schon 7 Stunden drauf, bis man den richtigen Einstiegspunkt in die „Transaktion“ (oder wie auch immer das dort heißt) gefunden hat. Und die meisten Inhalte lassen sich dann mit SAP-Mitteln generieren, sodass der Entwickler eigentlich fast gar nichts mehr tun muss.

In eine ähnliche Richtung gehen heutzutage immer mehr die Low-Code- oder No-Code-Plattformen. Da wird kaum selbst programmiert, sondern einfach was zusammengeklickt. Und da muss ich mich dann schon fragen lassen, wie ich „Anwendungsentwickler:in“ werden will, wenn ich gar keine Anwendung entwickle.

Aber es gibt auch Negativbeispiele aus anderen Bereichen. Mein persönliches Highlight aus einer Abschlussprüfung war eine einzelne HTML-Seite, die mit 20 Zeilen JavaScript angereichert wurde. Das Problem war, dass der Prüfling selbst überhaupt nicht verstand, warum dieses Projekt nicht ausreichend war. Sein:e Ausbilder:in hatte ihn offensichtlich überhaupt nicht darauf vorbereitet. Und er war sehr enthusiastisch und freute sich richtig über sein Projekt. Das tat mir dann wirklich leid, da die Schuld für dieses unzureichende Projekt sicherlich nicht beim sehr motivierten Prüfling zu suchen war.

Kurz gesagt sollte ein Abschlussprojekt zeigen, dass du methodisch Software entwickeln kannst, die eine gewisse Komplexität aufweist. Dazu habe ich in dieser Podcast-Episode noch viel mehr zu erzählen: Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung.

Es geht darum, dass du deine Fähigkeiten angemessen unter Beweis stellst. Du sollst methodisch Software entwickeln und die Projektarbeit wirtschaftlich umsetzen. Dazu gehört u.a. eine Betrachtung der Kosten und der Amortisation, der Einsatz von Modellierungs- oder Dokumentationsmethoden (z.B. ERM, UML, EPK, Mockups), das Erstellen sinnvoller Dokumentationen (z.B. für Kunden, Betrieb, Entwickler), das planvolle Vorgehen bei der Projektumsetzung (z.B. Projektplan, Iterationsplanung, Gantt-Chart), eine gute Qualitätssicherung (z.B. Unit-Tests, Abnahmeprotokoll) usw.

Wenn du dir nicht sicher bist, ob dein geplantes Programm als Abschlussprojekt ausreicht, dann frag deine:n Ausbilder:in oder deine:n Berufsschullehrer:in. Die sollten die nötige Erfahrung mitbringen und die Anforderungen der IHKen einschätzen können. Alternativ stell dein Projekt doch im Forum vor oder schreib mir eine Mail. Ich helfe dir gerne mit einer kurzen Einschätzung weiter – aber erst nachdem du diese Podcast-Episode gehört hast.

Der Beitrag Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186 erschien zuerst auf IT-Berufe-Podcast.

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

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.

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:

Fiktives Beispiel: Es soll eine bestehende Excel-Lösung abgelöst werden durch eine Webanwendung.

Du suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.

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.

Jetzt anmelden!

Der Beitrag Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung – IT-Berufe-Podcast #185 erschien zuerst auf IT-Berufe-Podcast.

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

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!

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.

z.B. Leistungsbeschreibung, Termine/Fristen, fällige Entgelte, Lasten- und Pflichtenheft (insb. bei Softwareerstellung), Konventionalstrafen, Haftung

Mit AGBs regeln Unternehmen ihre grundsätzliche Vertragsgestaltung, also Inhalte, die für alle Verträge gelten.

Beispielinhalte:

Ein SLA legt fest, wie Auftraggeber:in und Dienstleister:in bei wiederkehrenden Dienstleistungen zusammenarbeiten und welche individuellen Verantwortlichkeiten sie tragen.

Beispielinhalte:

*

Und dazu passend das Arbeitsbuch:

*

Der Beitrag Verträge, AGBs, SLAs – IT-Berufe-Podcast #184 erschien zuerst auf IT-Berufe-Podcast.

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

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.

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.

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

Der Beitrag Softwarequalität nach ISO 9126 – IT-Berufe-Podcast #183 erschien zuerst auf IT-Berufe-Podcast.

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

Demnach sind keine Programmiersprachen: HTML/XML (Auszeichnungssprache), CSS (Stylesheet-Sprache), SQL (Datenbankabfragesprache).

Programmiersprachen bringen meistens „eingebaute“ („native“) Funktionen mit, die direkt in der Syntax der Sprache formuliert werden können:

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:

Im Alltag sind die Identifikation und Auswahl einer für das jeweilige „Realweltproblem“ passenden Sprache wichtig. Viele Programmiersprachen haben Schwerpunkte bei ihrem Einsatz, weil sie für bestimmte Einsatzzwecke optimiert wurden oder dafür viele vorgefertigte Lösungen mitbringen.

Ein Programmierparadigma gibt die grundsätzliche Art und Weise vor, wie mit einer Programmiersprache entwickelt wird. Es definiert grundlegende Herangehensweisen und Prinzipien bei der Softwareentwicklung, aber auch ganz konkrete syntaktische Vorgaben. So legt es z.B. fest, mit welchen Konstrukten das Programm hauptsächlich arbeitet (z.B. Objekte in der Objektorientierung bzw. Funktionen in der funktionalen Programmierung als sogenannte „First Class Citizens“), wie Programme modularisiert werden sollten und auf welche Art und Weise Algorithmen vorzugsweise formuliert werden sollten („idiomatische Programmierung“).

Viele Programmiersprachen sind heutzutage sogenannte Multiparadigmensprachen, bieten also Konzepte aus mehreren Paradigmen an, z.B. Objektorientierung und funktionale Programmierung. Meist haben sie aber ein definierendes Paradigma, z.B. Objektorientierung bei Java.

Grundsätzlich kann man die imperative und deklarative Programmierung unterscheiden. Während bei der imperativen Programmierung (von lat. „imperare“ – befehlen) exakt vorgegeben wird, in welcher Reihenfolge der Computer welche Befehle wie ausführen muss, gibt man bei der deklarativen Programmierung (von lat. „declarare“ – erklären) lediglich vor, welches Ergebnis am Ende erreicht sein soll, und lässt den Computer den Weg dorthin selbst finden.

Beispiel:

Syntaktisch gibt es eigentlich nur die Unterscheidung zwischen Sprachen, die ähnlich zu C sind (insb. Klammern, Schlüsselwörter, Datentypen) oder eben nicht.

Beispiel Java (C-ähnlich):

Beispiel Ruby:

Die weitaus meisten Programmiersprachen sind textuelle Sprachen, aber es gibt auch grafische Programmiersprachen, bei denen die Algorithmen „zusammengeklickt“ werden können. Ein Beispiel ist Scratch.

Diese Liste ist nicht vollständig!

*

Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages (Pragmatic Programmers) (Affiliate)*

Der Beitrag Eigenschaften und Unterscheidung von Programmiersprachen – IT-Berufe-Podcast #182 erschien zuerst auf IT-Berufe-Podcast.

In dieser Sonder-Episode des IT-Berufe-Podcasts geht es um eine Stellenausschreibung als Softwareentwickler:in (m/w/d) bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG in Vechta.

Bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG aus Vechta, suchen wir zum nächstmöglichen Zeitpunkt Unterstützung im IT-Bereich. Wir schreiben aktuell eine Stelle als Softwareentwickler:in aus. Selbstverständlich sind Bewerbungen von Personen aller Geschlechter erwünscht.

Unter dem folgenden Link kannst du dir alle Details zu der ausgeschriebenen Stelle anschauen und findest auch die notwendigen Daten für deine Bewerbung bei uns.

Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen

Wir suchen zum nächstmöglichen Zeitpunkt einen Softwareentwickler (m/w/d) in Festanstellung, der uns bei der Umsetzung von Fachbereichsanforderungen unterstützt und Systeme weiterentwickelt und optimiert. Deine Schwerpunkte liegen auf der Java-Plattform, sowie der Entwicklung in der Programmiersprache Natural der Software AG.

Deine Aufgaben

Deine neue Abteilung

Die Abteilung IT-Anwendungsintegration freut sich auf dich! Neben den genannten Tätigkeiten ist die Abteilung auch für den Betrieb und die Weiterentwicklung weiterer Drittanbietersoftwareprodukte verantwortlich (bspw. das Enterprise-Content-Management-System, das Inputmanagemensystem, diverse Spezialanwendungen für die Arbeit in den Fachabteilungen). Teile der Entwicklung des Bestandsführungsssystems werden auch in unserer Abteilung durchgeführt.

Zu Beginn deine Tätigkeit bei der AO bekommst du einen erfahrenen Mentor an die Seite gestellt, der dir alle Fragen beantworten kann und dich in die ersten Aufgaben und Projekte einführt. Sowohl die technischen Systeme, als auch das Unternehmen selbst und unsere Produkte werden dir in kurzen Schulungen nähergebracht. Fachlich wirst du von den jeweiligen Teammitgliedern betreut und in die Infrastruktur eingeführt.

Die ALTE OLDENBURGER gehört übrigens zu den Siegern der Arbeitgeber-Wettbewerbe des internationalen Forschungs- und Beratungsinstituts Great Place to Work. Die ALTE OLDENBURGER zählt zu den zehn „Besten Arbeitgebern Niedersachsen/Bremen 2023“ und wurde darüber hinaus sogar auch als einer von 100 „Deutschlands besten Arbeitgebern 2023“ ausgezeichnet.

Der Beitrag Stellenangebot: Softwareentwickler (m/w/d) in Vechta – IT-Berufe-Podcast erschien zuerst auf IT-Berufe-Podcast.

Um Zahlensysteme, Zweierpotenzen und vor allem Binärzahlen geht es in der einhunderteinundachzigsten Episode des IT-Berufe-Podcasts. Der Inhalt ist auch als Video bei YouTube verfügbar.

Zweierpotenzen und Binärzahlen begegnen uns in der IT-Ausbildung an vielen Stellen. In dieser Episode erkläre ich die Funktionsweise von Zahlensystemen (Binär, Oktal, Dezimal, Hexadezimal) und gebe Beispiele für den Praxiseinsatz.

Das Video zu dieser Episode findest du bei YouTube hier: Zahlensysteme, Zweierpotenzen und Binärzahlen.

Zahlen werden aus einzelnen Ziffern zusammengesetzt. Die Dezimalzahl 123 besteht z.B. aus den Ziffern 1, 2 und 3. Die bekannten Zahlensysteme haben unterschiedlich viele Ziffern:

Das römische Zahlsystem hat auch mehrere Ziffern:

Anders als in den anderen Zahlensystemen werden die einzelnen Ziffern hier einfach aufaddiert. So entspricht die Zahl III der Dezimalzahl 3, da I + I + I = 3.

Außerdem können Ziffern abhängig von ihrer Platzierung in der Zahl eine unterschiedliche Bedeutung haben. MCM entspricht z.B. der Dezimalzahl 1900, da das C vor dem M von diesem abgezogen werden muss, also 1000 - 100 = 900 ergibt. MCM = M + (M - C) = 1000 + (1000 - 100) = 1900.

In den anderen Zahlensystemen, die wir in der Informatik häufig verwenden (nämlich Dualsystem, Oktalsystem, Dezimalsystem und Hexadezimalsystem), stehen die Ziffern einer Zahl immer für einen Faktor, der mit der Wertigkeit seiner Stelle multipliziert wird. Die Dezimalzahl 123 steht für 1 * 100 + 2 * 10 + 3 * 1.

Die Wertigkeit der Stelle ergibt sich aus ihrer Potenz mit der Basis des Zahlsystems. Die Basen der Zahlensysteme sind:

Nun werden die Stellen der Zahlen von rechts nach links beginnend mit 0 immer um 1 im Exponenten erhöht, um die Wertigkeit der Stelle zu berechnen. Beispiel im Dezimalsystem:

Im Dualsystem oder Binärsystem ist die Basis 2, die Wertigkeiten der Stellen der Zahlen lauten also:

Sie steigen also deutlich langsamer an als im Dezimalsystem. Mit jeder Stelle verdoppelt sich die Wertigkeit (im Vergleich zur Verzahnfachung im Dezimalsystem). Um den gleichen Zahlwert darstellen zu können, sind also deutlich mehr Ziffern nötig. Das wird noch deutlicher beim Hexadezimalsystem: Mit einer Ziffer können 16 verschiedene Werte dargestellt werden, also acht Mal so viele wie im Dualsystem.

Beispiel: Die Dezimalzahl 256 wird im Hexadezimalsystem als 100 (1 * 256 + 0 * 16 + 0 * 1) notiert, aber im Dualsystem als 100000000, hat dort also dreimal so viele Ziffern.

Im Dualsystem gibt es die Ziffern 0 und 1, die somit die „binary digits“ (binäre Ziffern) darstellen. Abgekürzt wird daraus Bit (binary digit).

Oft stellen wir uns die Frage, wie viele Kombinationsmöglichkeiten – also unterschiedliche Zahlen – es für eine gegebene Anzahl an Stellen geben kann. Im Dualsystem haben wir pro Stelle zwei Möglichkeiten: 0 und 1, also ein Bit. Für eine Zahl mit einer Stelle ergeben sich also zwei Möglichkeiten: 0 und 1. Für eine Zahl mit zwei Stellen verdoppelt sich die Anzahl der Möglichkeiten:

Und mit jeder weiteren Stelle verdoppeln sich die Möglichkeiten wieder, da vor jede bisherige Kombination wieder 0 oder 1 geschrieben werden kann:

Die Anzahl der Kombinationsmöglichkeiten oder unterschiedlichen Zahlen für eine gegebene Anzahl an Stellen lässt sich berechnen als Potenz aus Basis des Zahlsystems hoch der Stellenzahl. Für eine 5-stellige Dualzahl sind 2 ^ 5 = 32 Kombinationen möglich, für eine 3-stellige Oktalzahl 8 ^ 3 = 512.

Da in der IT das Dualsystem sehr wichtig ist – denn Computer können nur mit Nullen und Einsen rechnen – begegnen uns in der Praxis häufig immer wieder Zweierpotenzen, da die Basis des Zahlsystems nunmal 2 ist. Daher ist es wichtig, zumindest grob überschlagen zu können, wie viele Kombinationsmöglichkeiten es für eine gegebene Anzahl an Bits gibt. Ein paar wichtige Zweierpotenzen sollte man auch auswendig lernen, damit man nicht jedes Mal wieder nachrechnen muss:

Zum Abschluss habe ich hier noch eine Liste aller Zweierpotenzen bis 128 mit einigen Anwendungsfällen bzw. Namen. Die Beispiele passen natürlich nicht hundertprozentig (z.B. gibt es nicht exakt 2 ^ 33 Menschen auf der Erde und 2 ^ 20 ist nicht genau eine Million), aber vermitteln einen Eindruck ihrer Größe im Verhältnis zu den anderen Zahlen und helfen beim Überschlagen von Ergebnissen.

Der Beitrag Zahlensysteme, Zweierpotenzen und Binärzahlen – IT-Berufe-Podcast #181 erschien zuerst auf IT-Berufe-Podcast.