Der Podcast für Auszubildende, Ausbilder und IHK-Prüfer im Beruf Fachinformatiker für Anwendungsentwicklung. Stefan Macke gibt Tipps für die Ausbildung, die IHK-Prüfungen und alles was sonst noch mit dem Beruf des Anwendungsentwicklers zu tun hat. Aber auch für bereits ausgebildete Softwareentwickler/Programmierer und alle, die Interesse an der Softwareentwicklung haben, ist bestimmt etwas Interessantes dabei!
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.
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:
// imperativ for (int i = 0; i < list.getSize(); i++) { System.out.println(list.get(i)); } // deklarativ list.forEach(System.out::println);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):
void pruefePerson(int alter) { if (alter >= 18) { System.out.println("volljährig"); } }Beispiel Ruby:
def pruefePerson(alter) puts "volljährig" if alter >= 18 endDie 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!
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.
Um den Aufbau und den Ablauf der Abschlussprüfung in den IT-Berufen geht es in der einhundertachzigsten Episode des IT-Berufe-Pocasts.
Wer es ganz genau wissen will, schaut am besten in die jeweilige Berufsverordnung:
Die folgenden Zitate stammen aus der FIAusbV.
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.
Das Ergebnis des ersten Prüfungsteils geht zu 20% in die Abschlussnote ein.
Tipps zur Vorbereitung auf die Prüfung gibt es in meinen entsprechenden Podcast-Episoden, z.B. Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe. Und hier habe ich eine große Liste mit allen potentiellen Prüfungsthemen für dich zusammengestellt: Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen.
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:
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…
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:
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:
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.
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.
Die obigen Prüfungsteile gehen mit folgenden Gewichtungen in die Endnote ein (siehe FIAusbV §16 Abs. 1)
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.
Die Abschlussprüfung ist bestanden, wenn die genannten Prüfungsleistungen wie folgt bewertet worden sind (siehe FIAusbV §16 Abs. 2):
Das heißt, dass man quasi in Teil 1 der Prüfung nicht „durchfallen“ kann (sofern man die Note mit Teil 2 ausgleichen kann).
Ggfs. kannst du ein schlechtes Ergebnis im schriftlichen Teil 2 der Prüfung durch eine mündliche Ergänzungsprüfung ausgleichen.
Es gibt einen hervorragenden Notenrechner für die IT-Abschlussprüfung (AO2020).
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.
Der Beitrag Aufbau und Ablauf der IHK-Abschlussprüfung in den IT-Berufen – IT-Berufe-Podcast #180 erschien zuerst auf IT-Berufe-Podcast.
Um das beliebte Prüfungsthema RAID geht es in der einhundertneunundsiebzigsten Episode des IT-Berufe-Podcasts.
Der Beitrag RAID – Redundant Array of Independent Disks – IT-Berufe-Podcast #179 erschien zuerst auf IT-Berufe-Podcast.
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. Abgrenzung von Datensicherung, Datensicherheit und Datenschutz. Siehe auch...
Der Beitrag Datensicherung (Backup) – IT-Berufe-Podcast #178 erschien zuerst auf IT-Berufe-Podcast.
Your feedback is valuable to us. Should you encounter any bugs, glitches, lack of functionality or other problems, please email us on [email protected] or join Moon.FM Telegram Group where you can talk directly to the dev team who are happy to answer any queries.