Lizenzen in der Softwareentwicklung

Welche Lizenzen nutzen wir und wie unterscheiden wir zwischen diesen? Der Einsatz der jeweiligen Lizenzen richtet sich natürlich in erster Linie nach Art und um Umfang eines jeden einzelnen Projektes. In der Regel können wir zusammenfassen:

SOLID-Prinzipien in der Softwareentwicklung

Die SOLID-Prinzipien berufen sich auf die von Robert C. Martin in CleanCode beschriebenen Entwurfsmethoden einzelner Klassen. Was bedeutet das jetzt für uns?

Was bedeutet "SOLID"?

S = SRP: SingleResponsibilityPrinciple 

Jede Klasse hat nur eine Aufgabe. Die Methoden der Klasse sind einzig für die Aufgabe allein verwendet

O = OCP: OpenClosePrinciple

Klassen sind...

Datenschutz im Offboarding-Prozess - Zugriff auf E-Mails ausgeschiedener Mitarbeiter

Der E-Mail-Account ist noch da, der Mitarbeiter ist aber ausgeschieden. Darf der Arbeitgeber „einfach so“ auf die Mails in dem Account zugreifen? Oder ist das nur zulässig, wenn der Mitarbeiter einwilligt? Mit etwas gesundem Menschenverstand lassen sich diese Fragen leichter lösen, als viele befürchten.

Im Normalfall: keine Probleme 

Normalerweise sollte es so laufen: Ein Mitarbeiter scheidet aus dem Unternehmen aus. Der Grund dafür spielt dabei keine Rolle. In jedem Fall sollte er alle wichtigen Mails einem Kollegen übergeben, der sich künftig um darum kümmert.

Datenschutz im Offboarding-Prozess - Zugriff auf E-Mails ausgeschiedener Mitarbeiter

Unerwartete Hindernisse 

Manchmal läuft es freilich anders. Dazu ein Beispiel: Die Übergabe der Mails war für den vorletzten Arbeitstag des Mitarbeiters vorgesehen...

Requirements-Engineering - Designmethoden

Wie können wir aus groben Zielen und Vorgaben die Granularität von Anforderungen verfeinern und dabei Geschäftsprozesse (Use Cases) untersuchen? Wenn wir in der Softwareentwicklung über fachliche Anforderungen sprechen wollen, sprechen wir am Besten in der Sprache der Fachexperten. In der Sprache des Kunden! Dafür müssen Entwickler, Product Owner und Projektleiter die Fachsprache erlernen. Dieser Ansatz nennt sich Domain-Driven-Design (DDD).

Domain-Driven-Design (DDD) - Modellierung nach Fachlichkeit

Der Grundsatz dieser Methode lässt sich kurz zusammenfassen: "Wir konzentrieren uns ausschließlich auf den fachlichen Teil eines Themas und nicht auf mögliche technische Lösungen." Als Hilfsmittel zur Modellierung sei hier auf das Domain Storytelling verwiesen!

Was sind eigentlich die Vorteile des DDD?

• Die Kommunikation zwischen Fachexperten und Entwicklerteam ist frei von Störungen, denn es kann direkt über Prozesse, Abläufe oder Funktionen eingestiegen werden
• Fachexperten können Ihre Anforderungen präziser formulieren, da sie sich in ihrer Fachdomain befinden

Requirements-Engineering - Designmethoden

4000,- Fördermittel jetzt als Ostergeschenk

Die BAFA hat ein Förderprogramm aufgelegt, welches kleine und mittlere Unternehmen (KMU) und Freie Berufe mit bis zu 4000,- Zuschuss (muss nicht zurückgezahlt werden!) für Beratungen fördert.

Und jetzt das beste: yourIT darf Sie beraten.

Requirements-Engineering - Anforderungen identifizieren

In der objektorientierten Programmierung gibt es zwei Begrifflichkeiten, die jeder kennen sollte: Generalisierung und Spezialisierung (Vererbung).

Alle Gemeinsamkeiten eines Objektes werden ermittelt und in der Basisklasse beschrieben (Generalisierung). Die eigentliche Implementierung erfolgt in einer abgeleiteten Klasse (Spezialisierung). Daraus schließen wir:

Requirements-Engineering - Anforderungen identifizieren

Anforderungen an die Aufgabe recherchieren (Generalisierung)

Automatisierte Releasenotes - Transparenz in die Tiefe

Wer kennt sie nicht die ewigen Fragen: "Was sind die Highlights im aktuellen Release?" oder "Welche Bugfixes/Improvements konnten in das Release einfließen?"

Agiles arbeiten und der damit vermeintlichen Transparenz gegenüber Product-Owner, Stakeholder oder allgemein dem Management trotzt eine Phase des Requirements-Engineering, ja gar einer kompletten Iteration.

Es werden Anforderungen der Product-Owner und Stakeholder ermittelt, aufgenommen und aufbereitet (Requirements-Engineering). Es werden Priorisierungen des Backlogs, Sprintbacklogs und des Sprintlogs selbst durchgeführt. Am Ende steht die Frage in fast jedem Review-Meeting: "Welche dieser hier gezeigten Tickets werden in das kommende Release einfließen?". Dem Releasemanager drehen sich förmlich im Ansatz der zu erwartenden Frage die Fußnägel auf. Allerdings formuliert sich die Antwort auf die zu erwartende Frage schon, obwohl die eigentliche Frage noch überhaupt nicht gestellt worden ist: "Wozu führen und managen wir Komponenten und Versionen in unserer Planungs- und Releasephase?" 

Da sich diese Frage immer wieder stellt, haben wir uns als Software-Entwickler der yourIT dieser ewigen und immer wiederkehrenden Aufgabe gestellt. Als Ergebnis haben wir ein Maven-Plugin geschrieben, welches beim Bauen des Artefaktes die Releasenotes aus unserem Jira-Board abgreift, als HTML-Report aufbereitet und ins gebaute Artefakt mit einbaut. 

Im einfachsten Fall kann dieser Report im Review-Meeting herangezogen werden, da alle Tickets und Anforderungen, die gelöst wurden, darin aufgelistet sind. Im komplexeren Anwendungsfall werden die generierten Releasenotes automatisiert im Buildprozess eingepackt und sind für den Kunden jederzeit einsehbar.

Wie kompliziert ist das und was benötigen da jetzt genau?

Alles, was in der Maven-Konfiguration benötigt wird, ist ein von der yourIT geschriebenes Maven-Plugin:

<build>
  ...
    <plugin>
      <groupId>de.yit.yourit.maven.jira-releasenotes</groupId>
      <artifactId>jirareleasnotes-maven-plugin</artifactId>
      <version>1.0.0</version>

      <executions>
  <execution>
    <goals>
      <goal>jira-releasenotes</goal>
    </goals>
    <phase>compile</phase>
 </execution>
      </executions>
      <configuration>
  <jpql>component = "yourIT Webseite" and ..."</jpql>
  <jiraURL>http://0.0.0.0:8080</jiraURL>
  <username>jenkins</username>
  <password>*****</password>
  <target>${project.build.outputDirectory}/static/notes.html</target>
       </configuration>
    </plugin>

  ...

</build>

Im Buildprozess sieht es sehr unspektakulät aus:

[INFO] --- jirareleasnotes-maven-plugin:1.0.0:jira-releasenotes 

(default) @ website-app ---

Aber das Ergebnis ist dennoch Aussagekräftig:

ReleaseNotes - Report

Verantwortlich für diesen Beitrag: yourIT GmbH, Balingen, Zollernalbkreis