Datenbank Modelle ACID und BASE im Vergleich

Datenbanksysteme

In der Welt der Datenbanktechnologien sind zwei zentrale Konzepte weit verbreitet: das ACID-Modell, das typischerweise mit relationalen (SQL) Datenbanken assoziiert wird. Das BASE-Modell wird oft mit NoSQL-Datenbanken in Verbindung gebracht. Diese Modelle definieren die grundlegenden Eigenschaften, die von den jeweiligen Datenbanksystemen erwartet werden.

ACID-Modell

ACID steht für Atomicity, Consistency, Isolation und Durability. Dieses Modell wird in relationalen Datenbankmanagementsystemen (RDBMS) eingesetzt, um die Zuverlässigkeit und Genauigkeit von Transaktionen zu gewährleisten.

  • Atomicity (Atomarität): Jede Transaktion wird als eine einzelne Einheit betrachtet, die entweder vollständig erfolgreich ist oder gar nicht ausgeführt wird.
  • Consistency (Konsistenz): Transaktionen führen eine Datenbank von einem konsistenten Zustand in einen anderen über, ohne die Datenintegrität zu verletzen.
  • Isolation (Isolierung): Gleichzeitig ausgeführte Transaktionen beeinflussen sich nicht gegenseitig.
  • Durability (Dauerhaftigkeit): Sobald eine Transaktion abgeschlossen ist, bleiben die Änderungen dauerhaft erhalten, auch im Falle eines Systemausfalls.

BASE-Modell

BASE steht für Basically Available, Soft State und Eventually Consistent. Dieses Modell wird in NoSQL-Datenbanksystemen verwendet, um Flexibilität, Skalierbarkeit und Verfügbarkeit in verteilten Systemen zu gewährleisten.

  • Basically Available (Grundsätzlich verfügbar): Das System garantiert die Verfügbarkeit von Daten, auch wenn einige Teile des Systems ausgefallen sind.
  • Soft State (Weicher Zustand): Der Zustand des Systems kann sich mit der Zeit ändern, auch ohne Benutzereingriffe.
  • Eventually Consistent (Schließlich konsistent): Das System stellt sicher, dass, wenn keine neuen Updates mehr erfolgen, alle Replikationen der Datenbank nach einiger Zeit konsistent sind.

Vergleichstabelle

Eigenschaft ACID-Modell BASE-Modell
Datenintegrität Hoch Variabel
Flexibilität Gering Hoch
Skalierbarkeit Vertikal Horizontal
Konsistenz Strenge Konsistenz Eventuelle Konsistenz
Transaktionsmanagement Strikt und zuverlässig Locker und anpassungsfähig
Einsatzgebiet Traditionelle Unternehmensanwendungen Verteilte, skalierende Anwendungen

Fazit

Das ACID-Modell bietet hohe Datenintegrität und Zuverlässigkeit, was es ideal für Anwendungen macht, die strenge Konsistenz und Transaktionssicherheit erfordern, wie z.B. Bankensysteme. Allerdings kann es aufgrund seiner strengen Regeln zu Einschränkungen in Bezug auf Flexibilität und Skalierbarkeit kommen.

Im Gegensatz dazu bietet das BASE-Modell eine hohe Flexibilität und Skalierbarkeit, was es ideal für verteilte Systeme und Anwendungen mit großem Datenvolumen und hohen Benutzerzahlen macht, wie soziale Netzwerke oder Echtzeit-Analysen. Die eventuelle Konsistenz kann jedoch zu Herausforderungen in Anwendungen führen, die eine sofortige Datenkonsistenz erfordern.

Letztendlich hängt die Wahl zwischen ACID- und BASE-Modellen von den spezifischen Anforderungen und dem Kontext der jeweiligen Anwendung ab. Beide Modelle haben ihre Berechtigung und bieten unterschiedliche Vorteile, die je nach Einsatzgebiet entscheidend sein können.

 

Vergleich von Skizzen, Wireframes, Mock-ups und Prototypen

GUI Entwicklung

In den 1970er Jahren führte das Xerox Palo Alto Research Center in der Software Entwicklung Konzepte wie Fenster und Icons ein, die von Apple im Macintosh von 1984 bekannt gemacht wurden. Später trugen IBM, sowie Microsoft mit OS/2 und Microsoft mit der Einführung von Windows in den 1980er Jahren zur Verbreitung von GUIs bei. Auch Commodore mit dem Amiga und Atati mit dem Model ST entwickelten hervorragende GUIs.

Durch das Aufkommen des Internets mit HTML wurden in den 1990er Jahren webbasierte Oberflächen gefördert. Die mobile Revolution, angeführt durch Geräte wie Apples iPhone, prägte die 2000er Jahre mit der Entwicklung von Touchscreen-orientierten GUIs auf mobilen Geräten. Heute setzen moderne Trends in Bereichen wie KI, Augmented und Virtual Reality, sowie Responsive Design neue Maßstäbe. Dies ermöglicht eine immer nahtlosere Integration von Geräten und Plattformen.

Bei der Softwareentwicklung werden Skizzen, Wireframes, Mock-ups und Prototypen in verschiedenen Phasen des Designs verwendet, um Ideen und Konzepte zu visualisieren. Hier sind die Unterschiede:

Skizzen

Eine Skizze ist eine handgezeichnete oder grobe digitale Darstellung einer Idee. Ein Designer zeichnet schnell ein paar Striche auf ein Papier, um die grundlegende Anordnung von Elementen auf einer Seite darzustellen. In dieser frühen Phase können grundlegende Ideen gefunden werden.

Design Skizze zur Planung

Wireframes

In dieser Phase der Konzeption werden die Struktur und Funktionalität definiert. So folgt eine detailliertere, schematische Darstellung der Benutzeroberfläche in Schwarz-Weiß. Ein Wireframe zeigt die Position von Menüs, Schaltflächen und Textblöcken, aber noch ohne Farben oder Bilder.

Wireframe bei der Entwicklung

Mock-ups

Nun wird die Designphase genutzt, um das visuelle Erscheinungsbild zu entwickeln. Eine realistische, aber statische Darstellung des Designs mit Farben, Bildern und Typografie wird gesucht. Ein Mock-up einer mobilen App zeigt, wie die Endversion aussehen könnte, ist aber nicht interaktiv.


Mockup

Prototypen

Die letzte Entwicklungsphase nutzt Prototypen, um Benutzerinteraktionen zu testen und Feedback zu sammeln. Es wird eine funktionierende Simulation des Produkts, die Interaktion ermöglicht. Ein Prototyp, auf dem Nutzer klicken können, um durch die Seiten zu navigieren und erfahren, wie die GUI in der Endversion sein wird.

Fazit

Insgesamt sind diese Tools Schritte in einem Prozess, der von einer groben Idee (Skizze / Stetch) über ein strukturiertes Layout (Wireframe) und ein realistisches Design (Mock-up) bis hin zu einer funktionierenden Version (Prototyp) reicht, die die endgültige Benutzererfahrung simuliert.

 

Agiles Projektmanagement mit Kanban

Kanban Logo

Kanban ist eine Methodik zur Optimierung von Arbeitsabläufen, die ursprünglich in der japanischen Automobilindustrie entwickelt wurde. Sie basiert auf dem Prinzip der visuellen Darstellung von Aufgaben, deren Status und Fortschritt, meist auf einem „Kanban-Board“. Dies hilft dabei, Engpässe zu identifizieren, die Arbeitslast zu regulieren und die Effizienz des Teams zu steigern

Wie funktioniert Kanban?

Ein Kanban-System ist ziemlich einfach aufgebaut. Es besteht normalerweise aus einem physischen oder digitalen Kanban-Board und darauf platzierten Kanban-Karten.

Kanban Tafel

Das Kanban-Board ist in mehrere Spalten unterteilt, die den unterschiedlichen Stadien des Arbeitsprozesses entsprechen. Die einfachste Form hat drei Spalten: „Zu erledigen“ (To Do), „In Arbeit“ (In Progress) und „Erledigt“ (Done).

Jede Aufgabe im Arbeitsprozess wird auf einer separaten Kanban-Karte dargestellt. Diese Karte enthält Informationen wie die Aufgabenbeschreibung, den verantwortlichen Mitarbeiter, das Startdatum und das Fälligkeitsdatum.

Wenn eine neue Aufgabe ansteht, wird sie als Karte in die „Zu erledigen„-Spalte eingefügt. Wenn jemand an der Aufgabe arbeitet, wird die Karte in die „In Arbeit„-Spalte verschoben. Sobald die Aufgabe abgeschlossen ist, wird die Karte in die „Erledigt„-Spalte verschoben.

Beispiel zur Nutzung von Kanban

Angenommen, Sie sind Teil eines Softwareentwicklungsteams. Die Kanbantafel des Teams könnte so aussehen:

Zu erledigen
1. Funktion zur Benutzeranmeldung erstellen
2. Datenbank für Benutzerinformationen einrichten
3. Design der Startseite entwerfen

In Arbeit
1. Backend für die Benutzeranmeldung entwickeln
2. Testen der Anmeldungs- und Abmeldefunktionen

Erledigt
1. Spezifikationen für die Anwendungsfälle erstellen
2. Entwurf des Anmeldeformulars

Jeder im Team kann den Status jeder Aufgabe auf der Kanbantafel sehen und so schnell erkennen, welche Aufgaben Priorität haben und wer gerade welche Aufgabe bearbeitet.

Die Grundregel des Kanban-Systems ist es, die Anzahl der gleichzeitig „in Arbeit“ befindlichen Aufgaben zu begrenzen. Diese Begrenzung wird als „Work in Progress“ (WIP) -Limit bezeichnet. Das hilft, Überlastung zu vermeiden und sicherzustellen, dass Aufgaben vollständig abgeschlossen werden, bevor neue Aufgaben in Angriff genommen werden.

Es können Engpässe während der Entwicklung schnell erkannt werden und dadurch können passende Gegenmaßnahmen zur Verbesserung umgesetzt werden.

Fazit

Der Einsatz von Kanban in der Softwareentwicklung bietet eine einfache, aber effektive Methode zur Visualisierung und Kontrolle des Arbeitsflusses. Es fördert Transparenz, Zusammenarbeit und unterstützt die kontinuierliche Verbesserung. Durch die Einführung von WIP-Limits kann Kanban dabei helfen, Multitasking zu vermeiden und die Produktivität zu steigern. Insgesamt kann Kanban wesentlich dazu beitragen, die Qualität der Softwareprodukte zu verbessern und die Entwicklungszeiten zu verkürzen.

 

 

Die Entwicklungsphasen von DevOps

DevOps Logo

DevOps wird genutzt, um die Zusammenarbeit zwischen den Teams für Softwareentwicklung und IT-Betrieb zu verbessern.  DevOps fördert einen kontinuierlichen, automatisierten und schnellen Entwicklungs- und Bereitstellungsprozess.

Es reduziert die Zeit bis zur Markteinführung und erhöht die Softwarequalität durch frühzeitige Fehlererkennung und schnelle Korrektur. Darüber hinaus ermöglicht es die kontinuierliche Überwachung und Optimierung der Systeme. Das führt zu einer höheren Kundenzufriedenheit und einer verbesserten Geschäftsleistung.

Phasen von DevOps

Planung: Definiere Ziele und skizziere den technischen und wirtschaftlichen Plan für das Projekt.
Codierung: Schreibe und überprüfe den Code unter Berücksichtigung der geplanten Spezifikationen und Standards.
Build: Kompiliere den Code, um die Lauffähigkeit herzustellen.
Test: Überprüfe und teste den Code auf Fehler und Leistungsprobleme.
Release: Setze die Änderungen in einer kontrollierten Umgebung frei. Überwache den Prozess, um sicherzustellen, dass es keine unvorhergesehenen Probleme gibt.
Deployment: Implementiere den Code in der Produktivumgebung, überwache seine Leistung und seine Auswirkungen.
Betrieb: Überwache und verwalte die Infrastruktur und die genutzten Anwendungen in der Produktionsumgebung.
Monitoring: Überwache die Leistung, sowie das Verhalten der Anwendung in der Produktionsumgebung und dokumentiere alle Probleme oder Ausfälle. Sie werden in zukünftigen Iterationen zu behoben. Sammle dabei Feedback und verwende es, um die Prozesse kontinuierlich zu verbessern (KVP).

Die Phasen bei DevOps wiederholen sich iterativ.

Fazit

DevOps stellt einen neuartigen Ansatz in der Softwareentwicklung und dem Operations Bereich dar, indem es eine nahtlose Integration und Zusammenarbeit zwischen den beiden Bereichen ermöglicht. Durch die Förderung von Geschwindigkeit, Effizienz und Qualität in der Softwarebereitstellung verbessert DevOps die Agilität und Reaktionsfähigkeit von Unternehmen. Das führt zu einer höheren Kundenzufriedenheit und verbesserten Geschäftsergebnissen. Trotz seiner Komplexität und der Notwendigkeit einer sorgfältigen Implementierung ist DevOps eine wertvolle agile Entwicklungsmethode, die den Weg für kontinuierliche Innovation und Verbesserung ebnet.

 

 

Requirements Mangement

Requirements Management Logo

Die Anfänge des Requirements Managements lassen sich auf die 1970er Jahre zurück verfolgen. Die Komplexität der Systeme begann, handgeschriebene Dokumentation und einfache Verwaltungstechniken zu übersteigen. In den 1980er und 1990er Jahren wurden strukturierte Methoden wie die Objektorientierung und spezialisierte Tools entwickelt, um die Verwaltung von IT Anforderungen zu formalisieren und die Nachverfolgbarkeit zu verbessern. In jüngerer Zeit hat der Aufstieg von agilen Entwicklungspraktiken das Requirements Management weiterentwickelt. Es wird ein kontinuierlicher, iterativer Ansatz zur Anforderungserfassung und -anpassung unterstützt.  So kann einfacher auf Änderungen reagieren werden.

Was ist Requirements Management?

Requirements Management bezieht sich im Bereich der Softwareentwicklung auf das Verstehen, Dokumentieren, Verfolgen und Aktualisieren von Anforderungen (engl. requirements). Diese Anforderungen können funktionale oder nichtfunktionale Eigenschaften sein. Ein Softwareprodukt muss diese Anforderungen erfüllen, um den Wünschen der Auftraggeber und Stakeholder zu entsprechen.

Aufgaben des Requirements Management

  • Erfassung und Dokumentation von Anforderungen in einem verständlichen und messbaren Format
  • Priorisierung von Anforderungen basierend auf den Bedürfnissen der Stakeholder
  • Verfolgen von Änderungen in den Anforderungen während des gesamten Projektzyklus
  • Sicherstellung, dass alle Anforderungen während der Entwicklung und beim Testen berücksichtigt werden
  • Verwaltung von Kommunikation und Übereinstimmung zwischen den Stakeholdern hinsichtlich der Anforderungen

Fazit

Gutes Requirements Management und Kommunikation kann dazu beitragen Missverständnisse zu minimieren, sowie das Risiko von Fehlern zu reduzieren und die Qualität der Produkte zu verbessern.

 

 

Der Blackbox Test und der Whitebox Test

Der Blackbox-Test und der Whitebox-Test dienen dazu, die Qualität und Zuverlässigkeit von Software- und Systemlösungen sicherzustellen. Die Tests decken verschiedene Aspekte wie Funktionalität, Benutzerfreundlichkeit, Zuverlässigkeit und Sicherheit ab. Sie werden von Anwendungsentwicklern, Systemintegratoren und weiteren Berufen in der IT Sparte eingesetzt.

Der Blackbox Test

Der Blackbox-Test wird auch manchmal als Black-Box-Test beschrieben und ist ein Testverfahren, bei dem die interne Struktur oder das Design des zu testenden Systems nicht bekannt ist oder nicht berücksichtigt wird. Der Tester betrachtet das System als eine „Blackbox“, bei der er nur die Eingaben (Input) und die Ausgaben (Output) kennt. Der Fokus liegt auf der Überprüfung der funktionalen Anforderungen des Systems, wie z. B. ob es die erwarteten Ergebnisse liefert und ob es korrekt mit verschiedenen Eingabeparametern umgeht. Der Tester kann verschiedene Techniken wie Äquivalenzklassenbildung, Grenzwertanalyse, Zustandsübergangstests und zufällige Tests verwenden, um die Wirksamkeit des Systems zu überprüfen. Der Blackbox-Test ermöglicht es, das System aus Sicht des Endbenutzers zu bewerten und kann unabhängig von der internen Implementierung des Systems durchgeführt werden.

Vorteile des Blackbox-Tests

  • Der Blackbox-Test stellt sicher, dass das System den Anforderungen und Erwartungen der Benutzer entspricht.
  • Der Blackbox-Test kann unabhängig von der internen Implementierung durchgeführt werden.
  • Durch den Blackbox-Test können Muster von Fehlern und unerwartetem Verhalten erkannt werden.

Nachteile des Blackbox-Tests

  • Der Blackbox-Test kann bestimmte interne Codepfade oder -bereiche nicht ausreichend testen.
  • Die Ursache von Fehlern kann aufgrund fehlenden Zugangs zur internen Implementierung schwierig zu identifizieren sein.
  • Der Blackbox-Test bezieht sich nicht auf die interne Effizienz oder Optimierung des Codes.

Der Whitebox Test

Der Whitebox-Test wird manchmal als White-Box-Test beschrieben und ist ein Testverfahren, bei dem der Tester Einblick in die interne Struktur, sowie in das Design des zu testenden Systems hat. Der Tester analysiert den Quellcode, die Algorithmen, die Datenstrukturen und andere technische Aspekte des Systems, um Tests zu erstellen, die auf diesen Informationen basieren. Der Whitebox-Test konzentriert sich sowohl auf die Überprüfung der funktionalen Anforderungen als auch auf die strukturelle Abdeckung des Codes. Es werden Techniken wie Pfadabdeckung, Anweisungsabdeckung, Zweigabdeckung und Bedingungsabdeckung verwendet, um sicherzustellen, dass alle möglichen Pfade und Szenarien im Code getestet werden. Der Whitebox-Test wird oft von Entwicklern durchgeführt, um sicherzustellen, dass der Code richtig implementiert ist und potenzielle Fehler und Schwachstellen identifiziert werden.

Vorteile des Whitebox-Tests

  • Der Whitebox-Test ermöglicht eine detaillierte Überprüfung des Codes und identifiziert potenzielle Fehler auf algorithmischer oder struktureller Ebene.
  • Durch den direkten Zugriff auf den Quellcode kann der Whitebox-Test eine umfassende Abdeckung der Code-Pfade und Szenarien erreichen.
  • Der Whitebox-Test ermöglicht es, ineffiziente Codebereiche zu erkennen und zu optimieren, um die Gesamtleistung des Systems zu verbessern.

Nachteile des Whitebox-Tests

  • Der Whitebox-Test erfordert Kenntnisse über die interne Implementierung, was zu Einschränkungen führen kann, wenn der Quellcode nicht verfügbar oder komplex ist.
  • Der Whitebox-Test fokussiert sich stark auf die interne Logik und kann die Perspektive eines Endbenutzers oder externe Schnittstellen möglicherweise nicht vollständig berücksichtigen.
  • Der Whitebox-Test erfordert tiefgreifende Kenntnisse der internen Struktur und erfordert mehr Zeit und Ressourcen im Vergleich zum Blackbox-Test.

Fazit

Der Blackbox-Test ermöglicht eine unabhängige Bewertung der funktionalen Anforderungen aus Benutzersicht, während der Whitebox-Test eine detaillierte Überprüfung der internen Implementierung und eine umfassendere Testabdeckung bietet. Beide Testarten sind wichtige Bestandteile der Qualitätssicherung.

 

 

Continuous Integration und Deployment – CI/CD

Softwareentwicklung geschieht vielfältig und CI/CD spielt bei Anwendungsentwicklern eine wichtige Rolle. Continuous Integration und Deployment (CI/CD) ist ein Prozess in der Softwareentwicklung. So werden Änderungen an einer Anwendung schnell und effizient in die Produktion zu überführt. Dies geschieht durch eine kontinuierliche Integration von Code-Änderungen und Tests, sowie eine automatisierte Bereitstellung von Software-Updates.

In der traditionellen Softwareentwicklung erfolgt die Integration von Code-Änderungen oft erst am Ende des Entwicklungsprozesses. Dies führt oft zu Problemen bei der Integration, da die einzelnen Komponenten der Anwendung nicht richtig miteinander funktionieren. Durch den Einsatz von CI/CD werden Code-Änderungen hingegen kontinuierlich und automatisiert in die Anwendung integriert und getestet.

Continuous Integration (CI)

Continuous Integration (CI) bezieht sich auf den Prozess der kontinuierlichen Integration von Code-Änderungen in ein zentrales Repository. Dabei werden alle Änderungen automatisch gebaut und getestet. So wird sichergestellt, dass sich die Änderungen problemlos in die bestehende Codebasis integrieren lassen. Dadurch können Probleme frühzeitig erkannt und behoben werden.

Continuous Deployment (CD)

Continuous Deployment (CD) geht noch einen Schritt weiter als CI. Es benutzt  Prozesse zur automatisierten Bereitstellung von Anwendungs-Updates. Dabei wird der Code automatisch auf die Produktionsumgebung übertragen und in Betrieb genommen, nachdem er erfolgreich getestet wurde. Dies ermöglicht eine schnelle und effiziente Bereitstellung von Software-Updates. Ausfallzeiten werden minimiert.

Durch den Einsatz von CI/CD können Entwickler die Qualität ihrer Anwendungen verbessern, die Entwicklungszeit verkürzen und die Auslieferung von Software-Updates beschleunigen. Dabei ist es wichtig, dass die Entwickler regelmäßig Änderungen am Code vornehmen und diese Änderungen automatisiert testen. Durch die kontinuierliche Integration und Bereitstellung von Code-Änderungen wird sichergestellt, dass die Anwendung zu jeder Zeit stabil und funktionsfähig bleibt.

Fazit

Zusammenfassend ist Continuous Integration und Deployment ein wichtiger Bestandteil der modernen Softwareentwicklung. Es ermöglicht eine schnelle, sowie effiziente Bereitstellung von Software-Updates. Es hilft Unternehmen, ihre Anwendungen schneller und mit höherer Qualität auf den Markt zu bringen.

 

Relationale Datenbanken entwerfen

Der Entwurf relationaler Datenbanken spielt für Datenbankentwickler eine wichtige Rolle. Dabei wird das 3-Ebenen Modell eingesetzt. Das besteht aus drei Ebenen. Dies sind die externe-, die konzeptionelle- und die interne Ebene. Um die Entwicklung zu vereinfachen, wird häufig das Entity-Relationship Modell eingesetzt. Das wird auch ER-Modell oder ERM genannt.

Der Entwicklungsprozess

Der gesamte Entwicklungsprozess besteht aus mehreren Phasen.

AnforderungsanalyseDatenbank EntwicklungsprozessAnforderungsanalyse

Die Anforderungsanalyse beginnt damit, dass alle Anforderungen der Akteure gesammelt und ausgewertet werden. Dabei können die Akteure in Gruppen geordnet werden. Dabei stellen sich die W-Fragen:

  • Welche Daten werden verarbeitet?
  • Wie werden die Daten verarbeitet?
  • Was ist in der Datenbank abzulegen?
  • Welche Daten werden Wem zur Verfügung gestellt?
  • Wo werden die Daten verarbeitet und wo gespeichert?
  • Wann finden welche Prozesse statt?
  • Wer führt welche Tätigkeiten durch?

Konzeptioneller Entwurf

Beim konzeptionellen Entwurf gibt es verschiedene Vorgehensmodelle. Oft wird die Top-Down- oder die Bottom-Up Methode eingesetzt. Hier werden die Daten, die Prozesse, die Abhängigkeiten in Beziehung gebracht. Jetzt ist der richtige Moment zu entscheiden, welches Datenbank System (DBS) eingesetzt wird, außer die Anforderungen haben dies bereits festgelegt.

Logischer Entwurf

Beim logischen Entwurf findet die Umsetzung des konzeptionellen Schemas statt. Die häufigsten Abfragen sind auf Grund der Anforderungen bekannt und bereits beschrieben. Das Endergebnis ist eine normalisierte Tabellenstruktur, die keine Fehler und Redundanzen enthält.

Implementierung

Jetzt erfolgt die konkrete Umsetzung auf dem Datenbank System. Dabei wird auf ein gutes Laufzeitverhalten und auf Effizienz geachtet. Wichtig ist hier, dass nach den Regeln der KVP (Kontinuierlicher Verbesserung Prozess) die Datenbank optimiert wird. Es werden die Sichten, Relationen, Indizes und die Berechtigungen eingerichtet.

Test / Qualitätssicherung

Bei der Qualitätssicherung wird geprüft, ob die Anforderungen erfüllt sind. Zudem werden die während der Anforderungsanalyse festgestellten Kriterien geprüft. Optimal ist hier zusätzliches automatisiertes Testsystem zu nutzen, dass den ganzen Lebenszyklus des DBS genutzt wird. Das vermeidet wiederkehrende Fehler und optimiert die Qualitätssicherung.

Übergabe und Nutzung

Nach dem Abschluss der Qualitätssicherung findet die Übergabe des Systems statt. Dabei ist zu beachten, dass dies wie alle vorher beschriebenen Prozesse in schriftlicher Form dokumentiert sein soll. Das Übergabedokument wird nach erfolgreicher Abnahme durch den Auftraggeber unterzeichnet und damit ist der Leiter des Projekts entlastet.

 

Qualitätsanforderungen an Software

Standardsoftware wird nach unternehmensinternen Qualitätsrichtlinien programmiert und verkauft.
Wie ist das aber bei individuell erstellter Software?

Es gibt allgemeine Qualitätsrichtlinien, die aber vor der Auftragserteilung festgelegt sein sollten. Denn es gilt:

„Qualität ist die Erfüllung der Kundenanforderungen.“

8 Kriterien für Qualität bei Software Entwicklung

Es gibt wichtige Eigenschaften, die bei der Softwareentwicklung eine tragende Rolle spielen. Denn schließlich soll die Software während der Nutzungsdauer problemlos und kostengünstig eingesetzt werden können.

Benutzerfreundliche Bedienung

Ein Programm oder eine App sollen einfach zu bedienen sein. der Anwender soll möglichst ohne Hilfe zum Erfolg kommen.

Unempfindlich gegen Fehler

Eingabefehler sollen abgefangen werden, Fehlbedienung nicht möglich sein.

Integrität und Sicherheit

Die Daten und das System sollen gegen unberechtigte Zugriffe und Manipulation geschützt sein.

Korrekte Funktion

Bei der Eingabe, Verarbeitung und Ausgabe dürfen keine Fehler auftreten. Bei gleichen Eingeben muss stets das gleiche Ergebnis erscheinen.

Portable Verwendung

Die Software soll auf anderen Systemen nutzbar sein.

Überprüfbarkeit

Bei der Abnahme der Software soll der Prüfungsaufwand gering sein.

Kompatibel zu anderen Anwendungen

Die Software soll einfach mit weiterer Software verbunden werden können.

Erweiterbare und wiederverwendbare Eigenschaften

Die Software soll leicht mit neuer Funktionalität ausgestattet und vorhandene Funktionen erweitert werden können.

Fazit:

Software Qualität ist wichtig und entscheidet mit, wie die Nutzung im beruflichen Alltag stattfindet. Gerade bei den Projekten Industrie 4.0 und der zunehmenden Digitalisierung in allen beruflichen Bereichen ist fehlerfreie, hochwertige Software eine Basisvoraussetzung.

Was ist ein Algorithmus?

In unserem täglichen Leben benutzen wir immer wieder Algorithmen. Aber wenn wir erklären sollen, was ein Algorithmus ist, dann wird es schwierig.

Ein Algorithmus ist eine Anleitung, mit bestimmten Eingabedaten bestimmte Ausgabedaten zu produzieren und auszugeben. Mit anderen Worten:

Es ist eine Handlungsvorschrift, um ein Problem schrittweise zu lösen

Anforderung an Algorithmen in der Programmierung

  • Der Algorithmus muss vollständig beschreibbar sein
  • Das Rechenverfahren muss aus einzelnen Arbeitsschritten bestehen, die zur Lösung des Problems führen
  • Jeder Schritt davon muss zu einem eindeutigen Ergebnis führen
  • Bei gleichen Eingaben erhält man immer das gleiche Ergebnis
  • Das Verfahren muss zu einem Ergebnis führen
  • Der Algorithmus muss universell und auf alle Daten anwendbar sein

Wie wird ein Algorithmus notiert oder aufgeschrieben?

Insgesamt kann dieser in einer Sprache wie zum Beispiel in Deutsch aufgeschrieben werden. Allerdings kann ein Computer den Algorithmus im Regelfall nicht verstehen.

Wie kann ein Computer mit Algorithmen arbeiten?

Damit der Computer den Algorithmus versteht, werden Programmiersprachen eingesetzt. Dabei wird zwischen strukturierter und objektorientierter Programmierung unterschieden. Die meisten Programmiersprachen bieten ähnliche Möglichkeiten die Lösung einer Problemstellung zu beschreiben oder wie der Programmierer sagt, zu implementieren.

Wie kann ein Algorithmus dokumentiert werden?

Dazu kann die Unified Modeling Language UML eingesetzt werden. Hier können Algorithmen grafisch dargestellt werden. Dies stellt eine praktische Ergänzung zur textuellen Beschreibung dar.

 

Software Entwicklung mit dem agilen Manifest

Scrum basiert auf agile Methoden wird sehr häufig bei der Software Entwicklung eingesetzt. Agile Methoden der Software Entwicklung werden inzwischen häufig eingesetzt.

Ziele agiler Entwicklungsmethoden

  • Eine schlanke, flexible Softwareentwicklung ist umsetzbar
  • Abbau bürokratischer Hemmnisse
  • Regelbasierte Tätigkeiten in Rollen werden eingesetzt
  • Die Entwicklung, die Dokumentation und der Test sollen eine Einheit bilden
  • „Qualität ist die Erfüllung der Kundenanforderung“ – diese Qualität ist zu erreichen
  • Agile Entwicklung ist dort einzusetzen, wo es Vorteile bringt

Das agile Manifest

Dazu werden die beschriebenen Werte eingesetzt.

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Entwickelt wurde diese Vorgehensweise von Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas