Schlagwort-Archiv Software

VonHickyGreen

Das hat mich zum programmieren gebracht…

Es brauch gründe um etwas zu tun, mein Grund war einfach aber auch irgendwie vielschichtig

Ich spiele seit meiner Jugend Spiele an technischen Geräten, sei es Gameboy, Playstation, Super Nintendo, Nintendo 64 oder Sega. Ich mag Spiele die mich fordern nachzudenken aber auch Spiele die einen dazu bringen mal Ziele zu verfolgen. Ich will es nicht zu leicht haben aber natürlich auch kreativ abgeholt werden.

Es ist mir oft passiert das ich stundenlang in ein Spiel versunken bin, es gab auch auch mal Phasen, da gab es für mich keine schönen Spiele oder anders gesagt ich hab sie einfach nicht gefunden oder die Möglichkeit gehabt interessante Spiele zu Spielen.

Ja meine Eltern haben versucht vieles möglich zu machen, obwohl es finanziell nie einfach war, ich hab einige Konsolen gehabt über die Jahre aber immer relativ ausgewählte Spiele dafür. Ich habe einen Gameboy gehabt, sogar recht früh aber einen PC hatte ich erst 1999 im Haushalt und das war nicht meiner, ich konnte nicht einfach am PC sitzen und zocken wie es beim Gameboy der Fall war.

Ich hab das Glück das mein Vater auch gerne mal am PC spielen wollte und so kam ich ab und an, auch mit PC-Spiele in Berührung, gerade Strategie und Organisation von Dingen war meistens das was mein Vater kaufte, das war dann auch das wo mit ich aufwuchs.

Ich war 2009 dann an dem Punkt das ich Wirtschaftsinformatik studiert habe, nach dem ich gehadert habe in meinen gelernten Beruf zurück zukehren. Ein Grund für die Wirtschaftsinformatik war damals das ich mich für die Gamesbranche interessiert habe. Ich wollte verstehen wie das alles Zusammenhängt und auch das Programmieren hat mich fasziniert aber ich empfand das Studium als Schwer, da es meinen Schwerpunkt der Begeisterung nicht ganz traf und dazu auch gefüllt war mit Inhalt der mich bis heute nicht positiv über das Studium denken lässt.

Ich lernte im Studium die Sprache C kennen, einen wirklichen Grund hat man nie genannt, nur das man als Bindeglied zwischen Wirtschaft und Informatik verstehen sollte was die Informatik da so macht. Das hätte man aber mit jeder anderen Sprache genauso zeigen können. Viele Sprachen basieren auf C oder haben sie als Vorbild oder als abschreckendes Beispiel aber sofern man nicht wirklich extrem Hardware nah programmiert ist C eine Möglichkeit(besser find ich da aber C++) um mit Atombomben auf Spatzen zu schießen. Das und andere merkwürdige Entscheidungen der Fachhochschule hat viele von uns damals das Studium extrem erschwert und das leider ohne Grund. Ich arbeite nun schon einige Jahre und interessiere mich für viele Felder aber ein wirklicher C-Programmierer ist mir nur einmal über den Weg gelaufen und der hat die Sprache für seine privaten Hobbys benutzt.

Ich brach das Studium dann leider wegen einiger Gründe am Anfang des dritten Semesters ab, ein Grund war auch die C Problematik. Es irritiert mich bis heute das man eine Branche die seit Jahrzehnter nach Arbeitnehmern bettelt so praxisfern ausbildet.

Ich studierte dann Betriebswirtschaft, war aber nie ganz weg aus der Informatik und beschäftigte mich phasenweise immer wieder mit der Programmierung, auch mit Themen die höherrangig gesehen werden sollten. Ich bin bis heute der Meinung das programmieren sehr wichtig ist aber gerade mit dem auf schwappen der AI/KI-Welle zeigt sich, das es sehr wichtig ist zu verstehen warum etwas gemacht wird und die Softwareentwicklung ehr im Vordergrund rücken muss und nicht die reine Fähigkeit code lesen zu können. Es ist schön das jemand versteht, das es eine Schleife ist die dort angewendet wird aber warum man diese dort wählt ist viel wichtiger.

Ich habe schon einige Firmen gesprochen, mein Grund für die Informatik ist das entwickeln von eigenen Spielen, das heißt nicht das ich anderen Branchen im Informatikumfeld nichts abgewinnen kann, viele Personaler drehen mit den Augen wenn sie das als Grund hören aber was will ich Lügen, ich bin nicht wegen WordPress und PHP an der Informatik interessiert, sondern weil ich Dinge erschaffen möchte.

Ich bin kein Entwickler geworden weil es mir so unfassbar Spaß macht im Support zu arbeiten oder Internetseiten stumpf immer wieder mit den simpelsten Mechaniken runter zu tippen. Ich mach das auch mal und bin gerne bereit solche Aufträge entgegenzunehmen aber das sind nicht die Aufträge die mich in die Informatik getrieben haben.

Ich entwickle seit 2020 Spiele für mich und meine Familie, immer mal wieder kleine Spiele. Meine Kinder finden Sie toll, ich merke wie ich jedes mal mit Begeisterung dabei bin wenn ich darüber nachdenke oder mitten dabei bin.

Ich will mich daher nebenberuflich selbstständig machen um meine eigenen kleinen Spiele zu entwickeln, nicht im Vollerwerb, gerne aber auch mit Leuten die Bock haben. Ich sehe nicht das ich den nächsten großen Hit programmiere und Millionen verdiene, es wäre schon cool wenn ich kostendeckend arbeiten könnte neben meinem Haupterwerb. Ich will endlich das machen was mich in diese Branche gebracht hat und vielleicht eine Inspiration für Leute sein die jetzt gerade die Faszination an Computerspiele für die verschiedensten Plattformen entwickeln, vielleicht sogar meine eigenen Kinder.

VonHickyGreen

OSI Modell von ISO

Ohje … dieses Modell, es begleitet mich seit Monaten und es fühlt sich an wie ein Dschungel von theoretischem Wissen.

Es gibt auf dem ersten Blick eigentlich nicht so viel über das Open Systems Interconnection(kurz: OSI)-Modell zu erzählen, doch ist dieses Modell für Netzwerkprotokolle als Schichtenarchitektur schon extrem wichtig und es hängt Rattenschwanzartig mit so vielen komplexen Themen zusammen die in der Ausbildung zum Fachinformatiker wichtig sind, das ich doch schon sehr tief abtauchen kann.

1. Bitübertragungsschicht

Diese Ebene wird auch Physical Layer im englischen genannt, wodurch sich zusammen mit dem deutschen Namen schon erahnen lässt, für was diese Schicht zuständig ist.

Sie ist zuständig für die physische Übertragung von der kleinsten Einheit im Modell, den Bits. Es werden hier Kabel benutzt oder auch Bits über Wireless Lan also über Antenne übertragen.

Dieser Layer kommt mit dem Ethernet Protokoll aber auch mit dem RS-232 und dem IEEE802.11 Protokoll in Berührung.

2. Sicherungsschicht

Die Sicherungsschicht ist auch als Data-Link-Layer im englischen bekannt und beide Begriffe sowohl der deutsche als auch der englische, ergänzen sich zur Erklärung ganz gut.

Auf dieser Ebene wird geklärt wie der vollständige Datenpaket, in dieser Ebene „Frame“ genannt, vollständig und fehlerfrei beim korrekten Empfänger ankommen um dies zu gewährleisten werden dem Frame physikalische Adressen mitgegeben. Die Schicht ist in zwei Unterschichten geteilt, einmal die MAC-Schicht und einmal die LLC Schicht.

Brigde und Switche arbeiten als Hardwaregeräte in dieser Schicht, sowie auch Wireless Access Points.

Protokolle wie CSMA/CD aber auch ARP arbeiten in Schicht zwei.

2a – MAC-Schicht

Diese Schicht, auch Media Access Control(MAC)-Schicht genannt, vergibt eine Hardware-Adresse(MAC-adresse), durch das Protokoll IEEE802.1 und das völlig nebensächlich von der Übertragungsform Wlan(IEEE802.11) Ethernet (IEEE802.3) oder Bluetooth (IEEE 802.15).

Jede MAC-Adresse ist vom Hersteller konfiguriert und lässt sich vom Anwender nicht ändern In jedem Frame (Datenpaket) befinden sich die MAC-Adressen von Sender (Quelle) und Empfänger (Ziel).

Wenn der Frame am (vermeintlichen) Ziel angekommen ist, vergleicht die Empfangseinheit der empfangenden Station die MAC-Zieladresse mit der eigenen MAC-Adresse.

2b – LLC-Schicht

Die Logical-Link-Control-Schicht arbeitet eng mit der MAC-Schicht zusammen, sie ist hauptsächlich für die Steuerung und Verwaltung der Datenübertragung zwischen verschiedenen Netzwerkgeräten verantwortlich.

3. Vermittlungsschicht

In der dritten Schicht hilft uns die englische Übersetzung wieder weiter, weil Sie uns mit „Network-layer“ zusätzliche Anhaltspunkte auf den Tätigkeitsbereich gibt.

Es wird auf dieser Schicht möglich gemacht das Daten über Netzwerkgrenzen zum korrekten Empfänger kommen, das heißt ab der Schicht drei können Daten dein Heimnetzwerk verlassen und mit anderen kommunizieren.

Wenn man von den übermittelten Daten spricht, spricht man in dieser Schicht von Paketen, diese enthalten neben den Daten aus der Schicht ein und zwei auch noch logische Adressen.

Waren es in der zweiten Schicht nicht noch physische Adressen? Ja genau aber zu diesen gesellen sich jetzt die logischen Adressen, diese werden durch das IP-Protokoll erzeugt und sind dir bestimmt schon bekannt unter dem Namen „IP-Adressen“.

IP-Adressen

IP-Adressen sind die Adressen die das logische Ziel ausweisen, davon gibt es eine „alte“ Version, das ist die IPv4, da diese aber mit Ihren knapp 4 Milliarden Stück nicht ausreichend sind gibt es eine neue Version die seit einigen Jahren nach und nach ausgerollt wird, die IPv6.

4. Transportschicht

Jetzt haben für ja schon eine ganz schön große Menge Daten bis hier hin angesammelt, diese vierte Schicht sorgt jetzt dafür das diese große Menge an Daten vollständig und wenn nötig in korrekter Reihenfolge beim richtigen Bereich(Dienst) des angesprochen Systems(Empfängers) ankommt und das ganze durch Ports von Ende-zu-Ende-verschlüsselt ist.

Ports

Ports sind je nach dem was du ansprechen möchtest, die Tür zum entsprechenden Dienst. Port 80 spricht Http an, auch wenn http erst in Layer 5,6 und 7 zu finden ist (SPOILER😅), ohne dem du das hier gar nicht lesen könntest, wobei ich meinen Blog auf https laufen lasse, das wäre der Port 443 und selbst wenn du versuchst meine Seite über Http zu öffnen wird es immer eine Umleitung auf das Https Protokoll geben, weil es einfach sicherer ist. Es gibt aber viele wichtige Ports die man sich merken sollte gerade einige die unter den Well-Known-Ports(die ersten 1024) befinden.

TCP vs. UDP

Diese Schicht teilt sich jetzt wie Schicht 2 in zwei Bereiche, einmal in den Bereich TCP und dann in den Bereich UDP, sofern man von den versendeten Datenmengen innerhalb von TCP spricht, spricht man von Segmenten. Wenn man von Datenmengen innerhalb der UDP-Schicht spricht, dann spricht man von Datagrammen.

Meiner Kenntnis nach benutzt man UDP wenn man schnell Daten von A nach B verschicken muss und es dabei „nicht ganz so wichtig“ ist ob mal ein paar Datagramme unvollständig oder nicht in der richtigen Reihenfolge ankommen, z.b. beim Telefonieren über VoIP oder beim Streamen von Datenpaketen(Datagrammen).

In den anderen Fällen weicht man ehr auf das TCP-Protokoll aus und leitet dadurch die Datenmengen(Segmente) vollständig und in korrekter Reihenfolge zum richtigen Dienst des Empfängers.

5. Sitzungsschicht

Die fünfte Schicht, auch Sessionlayer genannt, ist nicht die Sitzung die du kennst wenn du eine Internetseite für eine Zeit lang besuchst. Diese Sitzungsschicht regelt die dauerhafte Kommunikation von Netzwerkteilnehmern aus unterschiedlichen Anfragen und Antworten zb Wenn der Warenkorb die Daten enthält die du vorher im Shop ausgewählt hast, mit der Anzahl und der Größe. Die Schicht ist für mich persönlich die abstrakteste Schicht und am schwierigsten zu visualisieren.

Es wird, neben den Protokollen die auch die Schicht 7 betreffen, das Protokoll RPC hier auf der Schicht ausgeführt, dass das Client-Server-Modell integriert und Aufgaben von Programmen erledigt, die in Clients und Server unterteilt werden.

6. Darstellungsschicht

Der Presentationlayer sorgt dafür das die Daten eine Syntax bekommen oder ein Encoding erhalten, sofern eines benötigt wird oder eine Verschlüsselung der Daten stattfindet oder auch diese komprimiert werden, sollte dies nötig sein. Ja, seit der Schicht 5, heißen die Datenmengen im übrigen einfach nur noch Daten, das bleibt auch bei Schicht 7 der Fall.

ASN.1 ist auf dieser Schicht zusammen mit den Protokollen von Schicht 7(die auch teilweise auf Schicht 6 und 5 wirken) genauso wie die Hardware die auf diese Schicht arbeitet.

ASN.1

Angenommen, wir haben ein Netzwerkprotokoll für den Austausch von Benutzerinformationen zwischen einem Server und einem Client. Die Informationen könnten den Benutzernamen, die E-Mail-Adresse und das Geburtsdatum eines Benutzers enthalten. Diese Informationen müssen in einer standardisierten Weise übertragen werden, unabhängig von den spezifischen Datenformaten auf Server- und Clientseite.

Hier kommt ASN.1 ins Spiel. Mit ASN.1 können wir die Struktur dieser Informationen definieren:

UserInformation ::= SEQUENCE {
username UTF8String,
email IA5String,
birthdate GeneralizedTime
}

In diesem Beispiel wird festgelegt welche Benutzerinformationen zu welche Datentyp passen vom Protokoll ASN.1

7. Anwendungsschicht

Der Applikationlayer hat nun alle Daten der unteren Schichten und sorgt dafür das die Semantik der Daten hinzukommt, also ist 39104 eine Postleitzahl oder eine Telefonnummer oder der Umfang in Millimeter von meinem rechten Bein und ob diese Daten anwendungsspezifische Daten und Befehle ein und ausgegeben werden.

Die wichtigsten Protokolle die ich hier nennen kann sind HTTP, FTP, SMTP, POP3-Protokolle. Die Hardware die hier aber auch in der Schicht 5 und 6 genutzt wird sind Gateway(dein Router), Loadbalancer, Proxy und Firewall.

VonHickyGreen

Anforderungen erheben

Wie fängt man denn jetzt nun an eine Software zu planen?

kurzes Vorwort:

Ich muss sagen, ich habe mir die letzten Tage mehrfach an das Thema versucht und ich glaube eine kompetente Erklärung die alles abdeckt ist in einem überschaubaren Beitrag kaum möglich. Ich denke niemand will hier einen Beitrag sehen mit 40.000 Wörter…

Das wird sich durch alle Themen ziehen, je nach dem wie tief man in einzelne Thematiken abdriften will, können wir hier ganze Bücher schreiben, einerseits kenne ich mich dann doch nicht so gut aus andererseits ist das nur ein Hobby und mir fehlt dazu dann doch etwas die Zeit.

Im Endeffekt möchte ich eine kleine Sammlung der wichtigsten Methoden, Begriffe und Standards aufarbeiten, die man dann für Fragen oder zur Lösung dieser heranziehen kann.

ANFORDERUNGEN FESTLEGEN

Der allseits anerkannte erste Schritt eine Software zu planen ist es die Anforderungen an die Software festzulegen.

Dazu muss man aber erstmal Wissen was Anforderungen einer Software sind, um diese festzulegen zu können.

Das heißt im Grunde welche Person ist von dem Projekt betroffen oder beteiligt (Stakeholder) und was erwartet dieser Stakeholder (eine Fähigkeit oder Eigenschaft, die ein System haben soll) von meiner Software.

Das ganze macht man mit einer Anforderungsanalyse:

Je nach Organisation geht man da etwas anders an die Sache ran bzw. von einem anderen Blickwinkel heran, jedoch gibt es 3 Schritte die in allen Varianten irgendwie vertreten sind.

  1. Ermittlung, Analyse
  2. Strukturierung und Abstimmung
  3. Prüfung und Bewertung

Ermittlung und Analyse

Nichts geht über…“ sagt man schnell mal aber Nichts geht über das Wissen welche Anforderungen wirklich gebraucht werden, ja wirklich! Du willst nicht Tage vielleicht sogar Wochen mit Dingen verbringen, für die dich keiner bezahlt, nicht in der Softwareentwicklung aber auch in keinem anderen Beruf, damit das nicht vorkommt ermittelt und analysiert man welche Anforderungen ein Projekt hat.

Alle Anforderungen des Kunden müssen so genau wie möglich beschrieben sein, es darf keine mit gemeinten Annahmen des Kunden über das zu entwickelnde System geben. Will der Kunde das das wirklich oder glaube ich nur zu Wissen das er es will, diese beiden Zustände können manchmal gewaltig von einander abweichen.

Anforderungen müssen eindeutig definiert sein das hilft extrem Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden. Will der Entwickler diesen Knopf dort in grün oder will er alle Knöpfe in grün.

Die Anforderungen sollten in einer Sprache und in einem Sprachniveau verständlich formuliert sein womit sich alle Seiten auskennen, soweit Fachsprache benutzt werden muss, sollte diese so genau wie möglich erklärt sein(Jeder ist ein Fachmann aber in seinem eigenem Gebiet, das sollte man berücksichtigen), eine verständlich und übersichtlich geschriebene Dokumentation der Anforderung die an alle beteiligten Seiten ausgegeben wird, kann im Zweifel viel Nachsprache und Probleme verhindern.

Jede Anforderung muss eindeutig identifizierbar sein, über eine Kennung oder oder ID sodass man im Nachgang immer ein identifizierbare Anforderung bekommt

Anforderungen sollten mit Abnahmekriterien(erreichbaren Ziel) verknüpft sein sodass man diesen in der Abnahme auch problemlos nachvollziehen kann, ob diese Anforderung erfüllt ist, dies ist der Weg um eine Anforderung vorwärts verfolgbar macht.

Wenn man eine Rückwärtsverfolgung möglich machen will, sollte jede implementierte Funktion einer Software kontrollierbar sein, aufgrund welcher Anforderungen sie erstellt wird, des weiteren sollten alle implementierten Funktionen widerspruchsfrei zu anderen Funktionen sein um die Anforderung konsistent zu halten.

Strukturierung und Abstimmung

Wenn du die Anforderungen erfasst hast, stellst du bei der ein oder anderen Anforderung schnell fest das sie im ersten Moment machbarer, realistischer, notwendiger sind als andere, deshalb beginnt nach der Erfassung der nächste logische Schritt, die Strukturierung und die Klassifizierung!

Anforderungen werden dadurch schnell übersichtlicher, das wiederum das Verständnis der Zusammenhänge zwischen den Anforderungen erhöht, jetzt kannst du als nach folgenden Gründen sortieren:

  • gibt es Anforderungen die abhängig von andere Anforderungen sind
  • gehören Anforderungen fachlich-logisch zusammen
  • Welche Anforderungen gehören zu welcher Benutzerrollen

Weitere Strukturierungsmöglichkeiten sind :

  • funktionale und nicht funktionale Anforderungen von einander abgrenzen oder
  • fachliche sowie technische Anforderungen (fachlich motiviert)
  • rein technische Anforderungen (technisch motiviert)
Tabelle Abgrenzung nicht funktionale von funktionalen Anforderungen

Die so strukturierten Anforderungen werden zwischen Kunde(oder einem Vertreter des Kunden) und des Entwicklers(oder einen Vertreter des Entwicklers) weiter verfeinert in dem durch einen iterativen Prozess sich dem besten Ergebnis angenähert wird!

Prüfung und Bewertung

Wenn die Strukturierung erfolgte oder sogar schon zum Teil während diese noch läuft, erfolgt die wichtige Qualitätssicherung der Anforderungen nach entsprechende Merkmale:

  • korrekt: Die Anforderungen müssen widerspruchsfrei sein
  • machbar: Die Anforderung muss realistisch sein
  • notwendig: Die Anforderungen müssen vom Kunden(Auftraggeber) gewollt sein
  • priorisiert: Es muss eine der Vorrang(Reihenfolge) von Anforderungen geklärt sein
  • nutzbar, nützlich: Die Realisierung muss ein produktives System im Auge behalten

Das Ergebnis dieser Informationen dient als Basis zum Beispiel für das Pflichtenheft auch wenn dieses gar nicht mehr so häufig anzutreffen ist, durch den starken Wachstum der letzten Jahre von agilen Projektentwicklungen, das wir unter anderem Scrum oder andere agile Methoden zu verdanken haben!

Es benötigt aber grundsätzlich in jeder Methode, sei wie agil oder auch nicht eine gute Aufnahme der Anforderungen

VonHickyGreen

Hier bin ich!

Der Anfang ist getan!

Ich sitze jetzt hier seit 3 Jahren und versuche immer wieder Anlauf um Anlauf etwas hinzubekommen das mich zufrieden auf das blicken lässt was ich veröffentlichen möchte, diesmal bekomme ich das hin und bau hier einen Blog den ich auch anderen zeigen kann! Die Themen haben sich fast gehalten, es sind jedoch Sachen in den letzten Jahren passiert die einige Themen verdrängt haben oder in der Priorität verschoben haben aber das das Leben ein Weg ist der sich auch verändern kann ist auch so ein Punkt den ich hier behandeln werde.

… anders machen ist nicht immer richtig

Ich wollte alles anders machen und viele besser als andere und das 100% genau so wie ich mir das „vorstelle“, dabei hab ich gar nicht das Vermögen es so hinzubekommen wie ich es mir „vorstelle“.

Es ist auch nicht richtig nur weil es anders ist und wer sagt denn das es von Anfang an perfekt sein muss, das ist mein utopischer Gedanke alles 100% richtig hinbekommen zu müssen.

Themen des Blogs

Ich hab mir lange einen Kopf gemacht was ich wie sagen möchten, welche Themen wichtig sind und hab dabei gemerkt, das ich mich gar nicht so krass beschränken muss. Wenn es ein Thema gibt das mich interessiert ist es die Technik, sei es aus Sicht eines Nutzers oder eines angehenden Softwareentwicklers. Der Punkt Familie, Vater ist mir auch sehr wichtig, jedoch möchte ich hier nicht über meine Kinder ranten(oh Gott diese Anglizismen), weil’s auch einfach nichts zu meckern gibt, sondern über die Sicht als Vater schreiben, die bestimmten Thematiken mit sich bringen.

Es ist mir aber auch wichtig über Dinge und Geschehnisse schreiben zu können die in der Welt beziehungsweise in meinen Blasen passieren, ich sehe hier auch Themen über Mental Health oder mal ein politisches Thema, jedoch wird das hier kein politischer Blog aber eines kann ich vorweg schon mal sagen #NoAFD.

Ich liebe meinen Garten und habe auch technische Hobbies die ich gerne mehr oder ausführlicher wieder machen würde und das natürlich auch dokumentieren oder mit Meinungen veröffentlichen, hier zählen zum Bleistift 3D Drucken, Simson Mopeds aufbauen(restaurieren aber auch Alltagstauglich machen) und reparieren dazu.

YouTube, Twitch und was da noch so alles drunter zählt ist ebenfalls ein Hobby, nicht nur das Streamen und das Aufnehmen von Content sondern auch die Technik und Software und das miteinander was so dazugehört.

„Ich hoffe da ist was bei“

Ich hoffe doch das ich da ein paar Themen treffe die dir zusagen, ansonsten ist der Blog im stetigen Wandel und wer weiß welches Thema hier besprochen und ganz hobbymäßig analysiert wird, vielleicht ist es ja etwas was erst in Zukunft hier Platz finden, deshalb immer schön wieder mal rein schauen und Themen checken, das wäre mir ganz lieb!