IT-Berufe-Podcast

Stefan Macke
  • 5,0 (153)
  • TECHNOLOGIE
IT-Berufe-Podcast

Der Podcast für Auszubildende, Ausbilder und IHK-Prüfer in den IT-Berufen (Fachinformatiker für Anwendungsentwicklung/Systemintegration/Daten- und Prozessanalyse/Digitale Vernetzung, IT-Systemelektroniker, Kaufmann für IT-Systemmanagement, Kaufmann für Digitalisierungsmanagement). Stefan Macke gibt Tipps für die Ausbildung, die IHK-Prüfungen und alles, was sonst noch mit den Berufsbildern zu tun hat. Aber auch für bereits ausgebildete Softwareentwickler/Programmierer/Administratoren und alle, die Interesse an der Softwareentwicklung oder IT haben, ist bestimmt etwas Interessantes dabei! https://it-berufe-podcast.de

  1. 12. AUG.

    Lastenheft und Pflichtenheft – IT-Berufe-Podcast #189

    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,

    42 Min.

  2. 6. MAI

    Teamarbeit bei der Softwareentwicklung mit Christian Kranert – IT-Berufe-Podcast #188

    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.

    1 Std. 3 Min.

  3. 15. APR.

    Datenbanktransaktionen, ACID, CAP-Theorem und BASE – IT-Berufe-Podcast #187

    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,

    1 Std. 18 Min.

  4. 18. MÄRZ

    Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186

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

    37 Min.

  5. 11. MÄRZ

    Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung – IT-Berufe-Podcast #185

    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

    1 Std. 46 Min.

  6. 8. JAN.

    Verträge, AGBs, SLAs – IT-Berufe-Podcast #184

    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,

    1 Std. 19 Min.

  7. 14.08.2023

    Softwarequalität nach ISO 9126 – IT-Berufe-Podcast #183

    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

    58 Min.

  8. 10.07.2023

    Eigenschaften und Unterscheidung von Programmiersprachen – IT-Berufe-Podcast #182

    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, a href="/java-ee-7-lernzielkontrolle-anwendungsentwickler-podcast-54" title="Java EE 7...

    1 Std. 43 Min.
Alle anzeigen (204)

5
von 5
153 Bewertungen

Info

Der Podcast für Auszubildende, Ausbilder und IHK-Prüfer in den IT-Berufen (Fachinformatiker für Anwendungsentwicklung/Systemintegration/Daten- und Prozessanalyse/Digitale Vernetzung, IT-Systemelektroniker, Kaufmann für IT-Systemmanagement, Kaufmann für Digitalisierungsmanagement). Stefan Macke gibt Tipps für die Ausbildung, die IHK-Prüfungen und alles, was sonst noch mit den Berufsbildern zu tun hat. Aber auch für bereits ausgebildete Softwareentwickler/Programmierer/Administratoren und alle, die Interesse an der Softwareentwicklung oder IT haben, ist bestimmt etwas Interessantes dabei! https://it-berufe-podcast.de

Informationen

  • Erstellt von
    Stefan Macke
  • Jahre aktiv
    2015 - 2024
  • Folgen
    204
  • Bewertung
    Unbedenklich
  • Copyright
    © Stefan Macke
  • Sendungswebsite
    IT-Berufe-Podcast

Das gefällt dir vielleicht auch

Melde dich an, um anstößige Folgen anzuhören.

Bleib auf dem Laufenden mit dieser Sendung

Melde dich an oder registriere dich, um Sendungen zu folgen, Folgen zu sichern und die neusten Updates zu erhalten.
Wähle ein Land oder eine Region aus

Afrika, Naher Osten und Indien

Asien/Pazifik

Europa

Lateinamerika und Karibik

USA und Kanada