Mischa Praxisexpret, Github-Expert
Nikita Teamsprecher, Serverorchestrierung
Arsene Client-Server Lösung, Camunda Expert
Ornella Cloud Lösung, DMN Expertin

Mischa Beschreibung des Projektfokus und Motivation
Nikita Entwicklung der Lieferantenanforderungen nach CMII-ACQ SSAD
Arsene Lösungsempfehlung mit rationaler Begründung nach AHP
Ornella Erhebung von Kundenanforderungen nach CMII-ACQ ARD

foliage ist ein junges Start Up, welches es modernes soziales Netzwerk entwickelt. Der Focus liegt bei Projekten und Aktivitäten, die die Benutzer erstellen und in Teams weiterentwickeln können. Es handelt sich um ein evolutioniertes Ticketsystem, orientiert auf Studenten, Schüler und engagierte aktive Menschen.
Im Rahmen von Auswahl und Anpassunge von IT-Diensten beschäftigen wir uns mit dem Problem der Sourcecode Verwaltung in der Microservice Architektur. Das Problem liegt daran, dass sich mehrere Entwickler mit den gleichen Modulen beschäftigen können. Ausserdem kann die Kommunikation zwischen einzelnen Modulen zu Konflikten führen, wenn Entwickler die Configuration von Schnittstellen unterschiedlich gestallten.
Das Lösungskonzept ist die Benutzung von Version control systems und die Unterteilung der Serverschicht auf Test- und Releaseserver. Dabei handlet es sich um die Anpassung von einem VC-Software, Erstellung von automatischen Tests und Releasefreigabe.
Darüber hinaus haben wir vor, ein OAuth-Service und offene API zu erstellen, die wir frei für die anderen Entwickler bereitstellen, z.B. für die Entwicklung von mobilen Applikationen oder Authorisierungsverfahren in externen Webapplikationen über unser Service.

Workshop Presentation.pdf

CMMI Prozessgebiete

Fur unser Projekt sind folgende Themen relevant:
SSAD

• SP 1.1 Identify Potential Suppliers -> @rodchenk
  
• SP 2.2 Establish Negotiation Plans -> @NickIvachshenko
  
• SP 2.3 Select Suppliers -> @biggymat
• SP 3.2 Establish Supplier Agreement -> @pouahang

ARD

• SP 1.2 Develop and Prioritize Customer Requirements -> @biggymat
• SP 3.1 Establish Operational Concepts and Scenarios -> @rodchenk
• SP 3.3 Analyze Requirements to Achieve Balance -> @NickIvachshenko
• SP 3.4 Validate Requirements -> @pouahang

Meilenstein 2.pdf

---

Develop a list of potential suppliers

Bei dem Umstieg auf Microservice Architektur wurde entschieden, die Microservices im Cloud zu deployen. Basierend auf den Anforderungen an Cloud-Dienste, wurden aus der Liste vier Cloudanbieter herausgearbeitet (Amazon Web Services, Microsoft Azure, Joyent, Kahu). In der unteren Tabelle sind diese Anbieter und ihre Eigenschaften detaliert dargestellt.

Kriterium	Amazon Web Services	Microsoft Azure	Joynet	Lightcrest
Preis	Pay-as-you-go, ab $2,430.90 (for a scalable app in containers)	Pay-as-you-go, ab VMs $0.008/h, App Service $0.013/h, Azure SQL $0.021/h	Pay-as-you-go, ab $1,296.13 (for a scalable app in containers)	K1: $1,265.25, K2: $2,536.28, K3: $3,619.47, K4: $3,162.25, K5: $5,349.33, K6: $7,033.48
Abrechnungsmodel	monatlich	monatlich	monatlich	monatlich
Cloud-Typ	hybrid	hybrid	public	hybrid und private
Unternehmensgrösse	gross	gross	mittel (125 Mitarbeiter)	klein (unter 50 Mitarbeiter)
Weitere Dienste	S3 (starage), EC2 (Virtual Servers), RDS/ DynamoDB/ Aurora für Datenbanken	Machine Lerning, SQL Azure, Kubernets (administration, deployment)	Node.js, Converged Analytics, Multi-Cloud Kubernetes, Container and VMs	DevOps on Demand, Source Control, Full-Stack Engineering, Security Tools
Kunden	RyanAir, Atlassian, Siemens, Adobe, vodafone	HP, Adobe, Bing, Shell, Siemens, Allianz	Dell, Samsung, Iron.io, HashiCorp, opbeat	WonderHowTo, Tweak, Walks of Italy, ATCO Software
Auf dem Markt seit	Anfang 2006	Februar 2010	Ende 2004	2012
Kundenzufriedenheit	96%	98%	keine Daten	92%
Uptime	von 99.00% bis 99.99%	99.99%	bis 100%	keine Daten
Weitere Vorteile	Unterstüzung von Ubuntu Server, CentOS, Microsoft Windows Server, Apache, Nginx, Open VPN, SSH	Trainings, dezentralisierte Infrastruktur, Logging und Metrics	Open Source, Gründer von Node.js, Container Native	Geeignet für StartUps und kleine Unternhmen

Communicate with potential suppliers concerning the forthcoming solication

Wir haben mit jedem der vier ausgewählten Cloud-Anbieter Online-Kontakt aufgenommen und über nähere Informationen komminiziert. Dies hat uns weitergeholfen, eine mögliche Zusammenarbeit basierend auf den repräsentierten Angeboten vorzustellen. Die letzten zwei Anbieter (Joynet und Kahu) zeigen wesentlich mehr Interesse an der Zusammenarbeit als AWS und Microsoft Azure. Die Anbieter haben jeweils ein Angebot für uns erstellt.

Verify participants who will evaluate supplier proposals

Die vorgestellten Angebote werden zunächst von IT-Abteilung in einer kleinen Runde von allen Entwicklern diskutiert und bewertet. Anschliessend wird der Techlead die restlichen Aspekte mit Finanzabteilung besprechen und am Ende wird die Schlussfolgerung gezogen. Die Entscheidung wird letztendlich von dem Techlead zusammen mit dem Finanzleiter getroffen.

Verify participants in supplier negotiations

Die Verantwortlichkeit für evenuelle Planänderungen und Abweichungen in der Architektur- und Entwicklungskonzept trägt der IT-Architekt. Bei solchen Fällen ist es mit Techlead dringend zu kommunizieren. Der Techlead trägt die restliche Verantwortung sowohl für technische als auch preisliche Aspekte.

---

Entwicklung und Verfeinerung eines Verhandlungsplans für jeden der in Frage kommenden Lieferanten auf der Grundlage der Bewertung der Lieferanten und ihrer Vorschläge.

• 1 Rollen und Verantwortlichkeiten der Mitglieder des Verhandlungsteams
  2 Personen:
  Techlead, der genau die Anforderungen vorliegt.
  Sprecher(auch Finanzleiter), der unmittelbar die Verhandlung durchführt und mit Unternehmens finanzielle Aspekte bekannt ist.
• 2 Zu verhandelnde Schlüsselfragen:
  Zeitgrenzen beim Einführung und Implementierung von Lieferantensoftware, Wartung und Instandhaltung Verfahren beim Hardwareservices, Softwareberater und Trainings beim neu Softwareimplementierung.
• 3 The sequence of events to negotiate issues:
  
  • Zuerst werden die allgemeinen Anforderungen und Kosten, falls nicht vordefiniert, abgefragt werden bzw. eine Auswahl aus verschiedene Möglichkeiten durchgeführt wird.
  • Zweitens werden nicht entscheidende Elemente präzisiert. Bei der Auswahl aus einigen Diensten/Applikationen wird eine genaue Analyse durchgeführt und eine Entscheidung getroffen.
  • In der letzten Verhandlungsphase wird die Laufbahnplan für Implementierung festgestellt, Auszahlungsplan und Option definiert, Fristen und Meilensteinen festgesetzt.
• 4 Externe Faktoren, die die Verhandlungen beeinflussen könnten; (z. B. andere ausstehende Geschäfte und strategische Pläne) sind schwer vorhersagbar, aber können durch ausreichende Unternehmens- bzw. Projektmanagement maximal reduziert werden.
• 5 Frühere Erfahrungen mit Lieferantenvereinbarungen zur Ermittlung früherer Positionen und Probleme (und Verhandlungsstile) werden dokumentiert und, falls da eine ausreichende Anzahl von befähigte Spezialisten und Notwendigkeit in solche Daten gibt, analysiert werden, um weitere potentielle Schwierigkeiten zu vermeiden und effiziente Strategie in Verhandlung zu entwickeln.
• 6 Zeitplan und Reihenfolge der Lieferantenverhandlungen sollen in Projektmanagement definiert werden und sind möglichst stabil (unverändert) zu planen.
• 7 Ziele für die einzelnen Verhandlungssitzungen werden vor der Verhandlung festgesetzt. Abhängig von der jeweiligen Besprechung wird eine Testgruppe gebildet, die Ziele und Chancen bestimmt, die Risiken begrenzt und schließlich eine ausgewogene Lösung des Problems finden kann.
• 8 Risiken, Folgen und Milderung Alternativen werden geplant, wo es möglich und wertvoll ist, um Kosten zu reduzieren, Stabilität des Arbeitsprozesses zu gewährleisten und potentielle Schaden zu vermeiden.

---

• 1 Revisions due to negotiations
• 2 Supplier Selection decision
  • Kennen Sie Ihre Bedürfnisse?
  • Geringwertige Waren liefern. z.B.: Büromaterial, erkennen was unerlässlich ist.
  • verbringen Sie Zeit mit Forschung?
  • Potenzielle Lieferanten zur Bonitätsprüfung
  • Zuverlässigkeit und Schnelligkeit
  • Stimmen Sie den Service -Levels zu, bevor Sie beginnen
  • Kaufen Sie nicht bei zu vielen Lieferanten ein
  • Nicht einen einzigen Lieferanten haben
• 3 Evaluation Reports. Am besten geben Sie ihnen eine kurze Zusammenfassung, in der Sie Ihre Anforderungen, Ihre Häufigkeit und Ihr Geschäfts Niveau zusammenfassen.

Fordern Sie ein Angebot an:

Es ist sinnvoll, potenzielle Lieferanten zu bitten, Ihnen einen festen Preis für beispielsweise drei Monate zu auch nach Rabatten für langfristige oder volumenstarke Verträge fragen.

Vergleichen Sie mögliche Lieferanten:

Wenn Sie das Angebot erhalten haben, vergleichen Sie die potenziellen Lieferanten in Bezug auf das, was Ihnen am wichtigsten ist. Beispielsweise kann die Qualität des Produkts oder der Dienstleistung von größter Bedeutung sein, während deren Standort keine Rolle spielt. Der Preis ist wichtig, aber es sollte nicht der einzige Grund sein, warum Sie einen Lieferanten wählen. Niedrigere Preise spiegeln möglicherweise Waren und Dienstleistungen schlechterer Qualität wider, die auf lange Sicht nicht die kostengünstigste Option darstellen. Seien Sie sicher, dass Ihr Lieferant eine ausreichende Marge zum angegebenen Preis erzielen kann, damit das Unternehmen wirtschaftlich rentabel ist. Vergewissern Sie sich, dass der von Ihnen eingesetzte Lieferant die Arbeit erledigt. Einige Lieferanten können Arbeit an Unterauftragnehmer auslagern. In diesem Fall sollten Sie auch den Unterauftragnehmer untersuchen, um festzustellen, ob Sie mit dieser Vereinbarung zufrieden sind. Wo immer möglich, ist es immer eine gute Idee, einen potenziellen Lieferanten persönlich zu treffen und zu sehen, wie sein Geschäft funktioniert. Wenn Sie wissen, wie Ihr Lieferant funktioniert, können Sie besser verstehen, wie er Ihrem Unternehmen helfen kann. Denken Sie daran, dass der Ruf Ihres Unternehmens anhand der Arbeitspraktiken Ihrer Lieferanten beurteilt werden kann. Es ist geschäftlich sinnvoll, die ethischen Dimensionen Ihrer Lieferkette zu berücksichtigen.

Vergleichen Sie mögliche Lieferanten:

Sobald Sie sich für die Lieferanten entschieden haben, mit denen Sie zusammenarbeiten möchten, können Sie mit dem Aushandeln der Geschäftsbedingungen und der Vertragsgestaltung fortfahren. In unserem Leitfaden erfahren Sie, wie Sie mit Lieferanten über den richtigen Deal verhandeln.

Negotiate with Supplier to determine the best fit for the Project

Tipps:

• 1 Selbstbewusst sein
• 2 Bloß nicht jammern
• 3 Stellen Sie Richtigen Fragen ZB: wie richtig sind wir für Sie, wie sieht es mit Ihrer Liefertreue aus.
• 4 Lieferanten Flexibilität testen.
• 5 Alternativen haben
• 6 sorgen Sie für ein Win- Win Situation nutzen Sie die Aussagen des verkäufers.

Select a Supplier to be awarded the Supplier agreement

Lieferantenvereinbarungen unterscheiden sich von Lieferant zu Lieferant, es gibt jedoch einige Details, die jedem Vertrag gemeinsam sind. Diese sollten umfassen:

• 1 Name und Adressen der beiden beteiligten Parteien.
• 2 Eine Beschreibung der Leistungen und Anforderungen des Lieferanten.
• 3 Zahlungsbedingungen und Zahlungshäufigkeit.
• 4 Vertraulichkeitsklauseln.
• 5 Erstattungen und Entschädigungsklauseln.
• 6 Unterschriften, Daten und ggf. Zeugen Unterschriften.

Dies ist keinesfalls eine endgültige Liste und es wird weitere Bedingungen und Bedingungen geben, die die Lieferantenvereinbarung ausmachen. Kunden und Lieferanten sollten in der Lage sein, sich hinzusetzen und den Vertrag abzuschließen, und es sollte kein Vertrag unterzeichnet werden, bis alle Bedingungen und Konditionen vereinbart sind. Wenn ein Kunde sich bezüglich der Bestimmungen und Bedingungen unsicher ist, sollte er entweder eine Erklärung verlangen oder die Vereinbarung an einen Experten weiterleiten, der in dieser Angelegenheit beraten kann. Es ist besser zu zeigen, dass die Bedingungen vor der Unterzeichnung nicht klar definiert sind, als auf das Auftreten eines Rechtsstreits zu warten und eine Haftungsklausel später plötzlich zu erheben. Es sollte niemals ein Vertrag oder eine Vereinbarung unterzeichnet werden, wenn der Kunde Zweifel hat.

---

In welche Prozesse ist/wäre foliage über den gesamten Lebenszyklus involviert?

Lebenszyklusphasen eines CRM-Systems auf Situation anwenden: Projektthema Auswahl -> Quellcode Programmierung -> Anpassung -> Vertrieb Relevante Prozesse in jeder dieser Phasen bestimmen: Projektsaufteilung, SW-Entwicklung, SW-Deployment, Kundenkommunikation.

Wer sind/wären die internen und externen Stakeholder eines CRM-Systems bei der foliage?

Interne Stakeholder: IT-Abteilungsleiter, IT-Teilprojektleiter, Entwickler Externe Stakeholder: Mitarbeiter Marketing- und Vertriebsabteilung, Hard- und Softwarelieferanten

Welche Erhebungstechniken sind in der gegebenen Anwendungssituation geeignet?

• Brainstorming in der IT-Abteilung
• Online Umfrage

Welche Ziele werden mit den Methoden verfolgt? Womit ist zu rechnen?

Brainstorming in der IT-Abteilung liefert groben Abriss über die Beziehung zwischen der Firma und den Kunden sowie ihr Zufriedenheitsgrad.
Online Umfrage sammelt Meinungen und Vorschläge von Kunden , um in einem effizienten CRM-System zu arbeiten.

Welche weiteren organisatorischen o. ä. Rahmenbedingungen sind zu berücksichtigen oder zu schaffen?

• Geforschte, nachgefragte und aktuelle Projektthemen bearbeiten.
• Projekte in zielorientierte Teile teilen
• Quellecode in möglichst vielen Programmierungprachen programmieren
• Zeitliche schnelle Lieferung des Auftrags

---

Kundenerwartungen sind in der Sprache des Kunden formulierte Anforderungen an eine durch einen Dienstleister erbrachte Leistung oder an ein durch einen Lieferanten geliefertes Produkt. Ursache von Kundenerwartungen sind die ↑Kundenbedürfnisse, d.h. das Verlangen der Kunden nach der Behebung eines subjektiv empfundenen Mangels. Typisch für Kundenerwartungen ist, dass sie aus der Perspektive des Kunden und in seiner Sprache formuliert sind. Für die Durchführung eines Projekts ist es deshalb notwendig, aus den Kundenerwartungen zunächst in der Sprache des Lieferanten formulierte ↑Kundenanforderungen abzuleiten. Aus diesen können dann messbare und überprüfbare ↑Abnahmekriterien entwickelt werden, die eine reproduzierbare Abnahmeprüfung ermöglichen.

---

Develop operational concepts and scenarios that include operations, installation, maintaince, support and disposal as appropriate

Beim Umbau einer monolitischen Architektur in eine lose gekoppelte Architektur entstehen viele technische und organisatorische Vorteile, wie z.B. höhere Sicherheit, lose Kopplung von Komponenten und als Konsequenz -- einfacheres Testen und Entwicklung von Modulen. Die Module werde in Services separiert, sie besitzen eigene Aufgabe und arbeiten unabhängig, aber sie sind mit den anderen Modulen verbunden. Die Kommunikation zwischen den Diensten erfolgt via HTTP Request oder Message Queue. Bei der Einführung von Microservice Architektur wurde eine Systematische Refactoring-Strategie verwendet, um sie möglichst fehlerfrei gestallten zu können.

• Zuerst werden die neuen Funktionalitäten nicht mehr innerhalb von monolithischer Anwendung entwickelt, sondern werden in komplett eigenständige Microservices umgesetzt. Dieses Service wird unabhängig von der Hauptanwendung entwickelt, bereitgestellt und skaliert.
• Im nächsten Schritt werden die GUI (Benutzerschicht) und der Anwendungsschicht (Bussines Logic Layer) separiert. Danach können beide Schichte selbständig entwickelt werden. Ab diesem Schritt kann das Entwicklerteam eventuell aufgeteilt werden, da es nun nicht mehr um eine grosse Anwendung handelt, sondern um zwei (oder mehr) kleinere Module.
• Anschliessend werden die restlichen Komponenten der monolitischen Anwendung in Microservices umgebaut. Dabei müssen die Entwickler die bestehenden Module extrahieren. Der Komplexitätsgrad kann dabei sehr hoch sein und deswegen müssen die Entwickler zuerst mit dem Modul starten, dessen Extraktion am einfachsten ist oder bei dessen Extraktion der grösste Mehrwert entsteht.

Für die Instandhaltung von Microservices bieten die Cloudanbieter etablierte Docker- und Kubernetes-Technologien. Das erlaubt es, den Remote Service effektiv sowie effizient in eine neue Generation zu führen und somit die Fernwartung und Instandhaltung zu optimieren. Das Deployment von Anwendung im Cloud wird mittels Anbietertools (CodeDeploy bei Amazon, Azure App Service bei Microsoft usw.) und mit "Pipelines" (YAML) durchgeführt.

Define the environment in which the product will operate, including boundaries and constaints

Das Cloud wird in drei Nutzungsszenarien aufgeteilt: Entwicklungs-, Test- und Deploymentumgebung. Dies hat eine Reihe von Vorteilen, wie z.B. Bedürfnissanpassung, Kostenerspranis und schnelle Einrichtung. Der Hauptgrund ist die vollständige Trennung von Test- und Entwicklungsumgebung. Dadurch soll potentieller Schaden für den produktiven Betrieb vermieden werden.

Review operational concepts and scanarios to refine and discover requirements

Das Betriebskonzept wurde überprüft und darauf bezogen wurde eine Liste von Anforderungen erfasst. Dies enthält organisatorische sowie technische Anforderungen. Zu den organisatorischen und finanziellen Anforderungen gehören Schulung, Support, Kosten, Leistungen, Chancen udn Risiken; zu den technischen Anforderungen gehören Uptime, Reaktionszeit, Sicherheit, Unterstützung von bekannten Technologien usw.

Develop a detailed operational concept, as candidate solutions are identified and product component solutions are selected by the supplier, that defines the intraction of the product, the end user, and the environment, and that satisfies operational, maintenance, support, and disposal needs

Das Betriebskonzept wird in folgende Aspekte unterteilt:

• 1 Erklärung des System und ihre Ziele
• 2 Strategien, Taktiken, Richtlinien und Einschränkungen, die das System beeinflußen
• 3 Zuständigkeitserklärung und delegierte Befugnisse
• 4 Prozesse zur Initiierung, Entwicklung und Wartung des Systems

Beim System handelt es sich um eine Cloud-basierte Entwicklungs- und Produktionsumgebung. Das System besitzt mehrere Nutzungsszenarien und wird zum Entwickeln, Testen, Demonstrieren und zur Releasefreigabe verwendet. Es wird eine klare Trennung zwischen den Nutzungszenarien gefordert um die maximale Sicherheit von Benutzerdaten sowie die Sicherung von Source code und dessen Versionen beschaffen zu können. Das System muss rund um die Uhr zur Verfügung stehen und es muss möglichst wenig Ausfälle geben. Darüber hinaus muss noch das Backup-System das planmäßige Datensicherung gewährleisten. Die Entwicklungsumgebung wird nur für die Entwickler, Testentwicklung für Tester und Entwickler und Backupsystem für Techlead und IT-Administrator zur Verfügung gestellt, um keine technischen Konflikte zu auszulösen. Die Gesamte Verantwortlichkeit für das System trägt der Techlead, der IT-Architekt ist für eventuelle Abweichungen im Plan verantwortlich und soll mit dem Techlead alle beeinflüßsten Merkmale besprechen. Allen anderen Beteiligten wird eine exakte Rolle zugeordnet, die dann dem System dabei hilft, die Autorisierungsrechte des Benutzers feststellen zu können. Das aktuelle System muss schrittweise in die neue Umgebung überführt werden. Dafür wird eine von Techlead zu bestimmende Deployment-Strategie verwendet. Diese wird je nach Cloud-Anbieter vor Ort geklärt. Auf der Entwicklungsumgebung muss die Hauptanwendung in einzelne Dienste (Microservices) extrahiert werden. Dafür wurde eine detalierte Refactoring-Strategie entwickelt. Die Wartung des Systems betrifft insbesondere die Entwickler, dabei handelt es sich um saubere und fehlerfreie Enwicklung. Die Richlinien für die Entwicklungs werden in Confluence(oder in einer alternativen Umgebung) erfasst. Das Logging, Automatisierung und Integration von einzelnen Modulen ins System wird mit Jenkins (Wikipedia) erfolgen. Damit kann auch der Status jeder Umgebung verfolgt werden. Falls es Konflikte oder Fehler auftreten, ist der Techlead für das Fixen verantwortlich. Im weiteren Verlauf soll noch Security Manager eingestellt werden. Er wird die Verantwortung für Sicherheit und das Security Compliance tragen. Anforderungen Analyse um Stakeholder Bedürfnisse zu balancieren und die Einschränkungen zu einstellen.

• 1 Die Bedürfnisse und Einschränkungen von Stakeholders können auf Kosten, Zeitplan, Produkt- oder Projektleistung, Funktionalität oder Risiken eingehen.
• 2 Die Anforderungen werden analysiert, um ein angemessenes Gleichgewicht zwischen Kosten, Zeitplan, Leistung und anderen Faktoren von Stakeholder zu bestimmen. Modelle und Simulationen können verwendet werden, um die Auswirkungen abzuschätzen, die Anforderungen an diesen Faktoren haben.
• 3 Risiken werden sofort ermittelt durch die Beteiligung von Stakeholdern in verschiedenen Phasen des Produktlebenszyklus. Wenn die Risiken als inakzeptabel angesehen werden, können die Anforderungen überarbeitet oder neu priorisiert werden, um das Verhältnis von Kosten, Zeitplan und Leistung zu verbessern.
• 4 Es ist sinnvoll eine Kosten-Nutzen-Analyse durchzuführen, um die Auswirkungen der Anforderungen auf die Akquisitionsstrategie und die Kosten und Risiken des Akquisitionsprojekts zu bewerten. Es wird auch hilfreich für Lieferanten Auswahl (SSAD SP 2.3)

Bewertung der mit den Anforderungen verbundenen Risiken

Eintrittswahrscheinlichkeit (zum Zeitpunkt der Bewertung):

• 1 Zweifelhaft <16% (Mu, Lambda)
• 2 Eher wahrscheinlich <17-50% (Kappa, Iota, Theta, Etha,)
• 3 Wahrscheinlich <51-84% (Zetha, Epsilon, Delta, Gamma)
• 4 Unvermeidlich >85% (Beta, Alpha)

Schaden bei Eintritt:

• C Gering, nicht relevante Prozesse gefährdet.
• B Mittel, wichtige Prozesse werden gefährdet.
• A Schwer, gefährlich für gesamtes Projekt.

Um vollständige Programm zum Erkennung und Analyse von Risiken zu erstellen, können weitere Praktiken aus der Prozessbereich Risikomanagement (RSKM CMMI-ACQ) verwendet werden.

AHP und CMMI Ausarbeitung.pdf

Vortrag.pdf

Mykhailo -> Koordinator, technischer Expert
Nikita -> Protokollführer, Sprecher
Ornella -> Mitarbeiterin

OAuth2 und Autorisierungs- und Authentificationsmodule in SOA am Beispiel von einem StartUp
Verschlüsselungskonzepte der Benutzerdaten in Entwicklungspfase (im StartUp)

Wir entwickeln ein projekt-, aktiviatäts- und zeitmanagementorientiertes soziales Netzwerk, das eine Alternative zum klassischen Ticketsystem (z. B. JIRA) darstellt. Es orientiert sich vor allem auf die jungen engagierten Menschen und nicht auf die Unternehmen. Da wir eine hohe Zahl von Benutzern erwarten, stellt sich die Frage, wie die Datensicherheit und der Datenschutz im Unternehmen bzw. im Netz gestaltet werden sollte. Darüber hinaus hat das deutsche/europäische Gesetz eigene Anforderungen, was die sozialen Netze betrifft.

TMG § 5 Allgemeine Informationspflichten
Dabei gilt es auch zu beachten, dass das Impressum mit maximal zwei Klicks erreichbar sein sollte, um die gesetzliche Vorgabe für ein „unmittelbar erreichbares“ Impressum nach dem Telemediengesetz § 5 zu gewährleisten.
TMG § 13 Pflichten des Diensteanbieters
Der Diensteanbieter hat den Nutzer zu Beginn des Nutzungsvorgangs über Art, Umfang und Zwecke der Erhebung und Verwendung personenbezogener Daten sowie über die Verarbeitung seiner Daten in Staaten außerhalb des Anwendungsbereichs der Richtlinie 95/46/EG des Europäischen Parlaments und des Rates vom 24. Oktober 1995 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr (ABl. EG Nr. L 281 S. 31) in allgemein verständlicher Form zu unterrichten, sofern eine solche Unterrichtung nicht bereits erfolgt ist. 2Bei einem automatisierten Verfahren, das eine spätere Identifizierung des Nutzers ermöglicht und eine Erhebung oder Verwendung personenbezogener Daten vorbereitet, ist der Nutzer zu Beginn dieses Verfahrens zu unterrichten. 3Der Inhalt der Unterrichtung muss für den Nutzer jederzeit abrufbar sein.
UrhG § 22
Gesetz betreffend das Urheberrecht an Werken der bildenden Künste und der Photographie
TMG, TKG usw. (Social Media Recht)

---

Für das Führen eines soziales Netzwerks haben Gründer die Pflicht ein paar Rechtlichen Anforderungen zu erfüllen. Dies dient zur Datenschutz und Datensicherheit aller Betreiber ,Behörden und Unternehmen des soziales Netzwerks. Dazu zählt:

• Vertraulichkeit
• Verfügbarkeit
• Integrität
• Nichtverkettbarkeit
• Transparenz
• Intervenierbarkeit

Alle oben genannte Anforderungen sind Bestandteile des Netzwerkdurchsetzungsgesetzes abgekürzt NetzDG. Die am 01.09.2017 Aktualisierung des NetzDG unterteilt dieses wiederum in mehreren unteren Gesetzen.

• §1 Anwendungsbereich
• §2 Berichtspflicht
• §3 Umgang mit Beschwerden und rechtswidrige Inhalte
• §4 Bußgeldvorschriften
• §5 Inländischer Zustellungsbevollmächtigter

Damit die Schutzziele des NetzDG in Kraft kommen, müssen erstmal die Betreiber berechtigt sein sich auf die Plattform anzumelden, um unbefugten Datenmissbrauch zu mindern. Die Open Authorization abgekürzt OAuth ist ein offenes Standarprotokoll, das eine API- Autorisierung ermöglicht.Das Bedeutet die Datenermittlung zwischen verschiedenen Anwendungen, Benutzeroberflächen oder Webseiten.

Die alte Architektur von unserer Web-Applikation hat nur über einen einzigen Eingang ins System verfügt. Das heißt, bei jeder Anfrage wurde geprüft, ob der Benutzer autorisiert ist, falls nicht → wird der Benutzer auf Login-Seite redirected. Login bzw. Regisitrierungsteil war monolithisch mit der Applikation verbunden und könnte nicht wiederverwendet werden. In dem aktuellen Architekturkonzept haben wir besorgt, dass Security-Verfahren möglichst flexibel gestalten ist, sodass es mehrmals für verschiedene Zwecke verwendet werden könnte. Beispielweise möchten wir es ermöglichen, sich an externen Web-Applikation über unseren Security-Modul authentifizieren zu können (OAuth2, siehe unten). Für hohe Flexibilität wurden alle Security-bezogenen Zeuge in ein externes Modul ausgelagert. Die Kommunikation zwischen Security-Modul und der restlichen Logik findet über eine Schnittstelle statt. Dieser Betrachtungsweise ermöglicht die Verteilung von Aufgaben und Verantwortlichkeiten innerhalb von Entwicklerteam. Darüber hinaus haben wir den Code für Security Modul von PHP auf Java mit Spring Security umgeschrieben. Dies bietet unterschiedliche Designmuster und Konzepte für ein sicheres und zuverlässiges Security-verfahren an. Das Verschlüsseln von Passwörtern erfolgt mit bcrypt Algorithmus. Die restliche Logik ist ebenso auf Java Spring umgeschrieben und dies verfügt über eine REST API Schnittstelle, d. h. jeder Ressource ist mit seinem Bezeichner zu finden. Das ermöglicht mehrere Eingänge ins System, aber diesmal ist nicht die Authentifizierung zu prüfen, sondern die Zugriffsrechte/ Autorisierungsrechte. Die Zugriffsrechte in unserem System sind in 8 Schichten aufgeteilt (von 0 bis 7). Der nicht angemeldete Benutzer hat die Zugriffsrechte 0, das heißt, er darf nur die Seiten angucken, die das Permission weniger als 1 haben, z.B. Login-/Registrierungsseite, Nichtprivate Accounts und Projekte von anderen Benutzern usw. Benutzer mit Zugriffsrechten 5 und 6 können die anderen Benutzer sperren/entsperren und die Einträge editieren/löschen. Die Benutzer mit den höchsten Zugriffsrechten 7 (Admin) verfügen über einen Gott-Modus im System. Die Authentifizierung mit Zugriffsrechten > 5 (interne Mitarbeiter) erfolgt über Zwei-Faktor-Authentisierung (2FA).

OAuth 2 ist ein Autorisierungsframework, mit dem eingeschränkten Zugriff auf Benutzerkonten in HTTP-Diensten gewährleistet wird. OAuth funktioniert auf originales Protokoll und unterstütz Web-, sowie Desktop- bzw. Mobile Applikationen.

Systemhierarchie und Konzept:

Kontoinhaber: Benutzer Der Benutzer autorisiert sein Konto. Der Zugriff einen Dienst auf dem Benutzerkonto ist beschränkt (lesende- oder schreibende Zugriff).
Ressourcenserver und Autorisierungsserver: API Der Ressourcenserver speichert die geschützten Daten von Benutzerkonten und der Autorisierungsserver verifiziert die Authentizität der vom Benutzer bereitgestellten Informationen und erstellt dann Autorisierungstoken für die Anwendung, über die die Anwendung auf Benutzerdaten realisiert wird. Aus Sicht des Anwendungsentwicklers führt die Service-API sowohl die Ressourcenserverrolle als auch die Autorisierungsserverrolle aus.
Client: externer Service
Applikation bzw. Dienst, die auf das Benutzerkonto zugreifen, muss vor dem Zugriff vom Benutzer autorisiert werden und die Autorisierung muss von der API kontrolliert werden.

OAuth und Autorisierungsmodule.pdf

---

Die OAuth unterscheidet sich in vier verschiedene Rollen

• Resource Owner
• Resource Serer
• Client
• Authorization Server

Weiterhin wird zwischen vier vordefinierten Genehmigungsprozessen (Grant Types) unterschieden, die in verschiedenen Anwendungsfällen zum Einsatz kommen:

• Autorisierungscode
• Implizite Autorisierung
• Passwortfreigabe durch den Resource Owner
• Client-Berechtigung

Wie auf der unteren Abbildung abgebildet ist, haben wir das Authorization Module als komlett unabhängiges Service ausgelagert. Dies ermöglichst die Wiederverwendung von Authorizationsfunktionalitäten. Darüber hinaus gibt es weitere Vorteile wie z.B. die Arbeitsverteilung, erweiterte Sicherheitsfaktoren und die Unabhängigkeit von Applikationslogik.

Before andere Applikationen unser Authorizationmodule verwenden können, müssen sie sich zuerst in unserem Entwicklerportal registrieren. Wir haben eine separate Datenbank, wo diese Angaben gespeichert werden. Die Struktur siehr folgendermassen aus:

app_id	app_name	reg_at
5235	Google	1542283375879
2340	THB	1542283400585
4327	Facebook	1542283400481
3299	foliage	1542283430509

Die folgende Tabelle zeigt auf welche privaten Inforamtionen die jeweilige Applikation zugreiffen darf, oder anders zu sagen -> welche Daten die Applikationen als Response bekommen wird.

app_id	data_id
3299	1
3299	2
3299	3
4327	1

Und die Tabelle mit Daten und jeweiligen IDs:

data_id	data_name
1	firstname
2	lastname
3	photos
4	friends

Nach der Registrierung bekommt die externe Applikationen einen einzigartigen app_id, die dann von ihrer Seite als Pflichtparameter übergeben wird, damit die API die Anfrage validieren könnte. Diese Anfragen müssen dann wie folgt aussehen:
api.foliage.com/login/?app_id=<app_id>

Unsere API bietet momentat drei Methoden an:

• api.foliage.com/login
• api.foliage.com/prolongate
• api.foliage.com/logout

Wenn ein auf foliage registrierter Benutzer auf einer externen Webseite/Applikation anmelden möchte und das jeweilige Service bietet diese Möglichkeit an, dann clickt der Benutzer auf das Button Anmelden über foliage.
Die Applikationen führt ein Redirect aus auf folgendes URL:
api.foliage.com/auth/login/?app_id=<app_id>&redirect_uri=<redirect_uri>
Die API prüft die Identität der Anfrage und der Client-Applikation und lädt die eigene Login-Seite. Der Benutzer gibt sein Benutzername und Password ein, bestätigt, dass er den Zugriff auf die aufgelistete Daten erlaubt und clickt auf Anmelden.
Die Anmeldedaten werden an die API gesendet, und von da an Authorizationmodule. Wenn die Anmeldung erfolgreich war, liefert die API eine JSON-Datei zurück:
{
    "status" : true,
    "access_token" : <access_token>,
    "expires_at" : 86400,
    "refresh_token" : <refresh_token>,
    "user" : {
         "name" : <name>,
         "photo" : <photo>
    }
}
Danach wird der Benutzer zurück redirected auf URL, was oben im ersten Befehl stand (redirect_uri=<redirect_uri>)
<redirect_uri>?access_token=<access_token>&refresh_token=<refresh_token>&expires_at=86400&name=<name>&photo=<photo_url> Der generierte Token ist 86400s gültig, danach muss sich der Benutzer entweder neu anmelden oder die Client-Applikation kann das automatisch mithilfe von refresh_token durchführen. Die automatische Verlängerung von access_token kann durch den Aufruf von der Methode api.foliage.com/prolongate durchgeführt werden. Die Anfrage an API soll folgendermaßen aussehen:
api.foliage.com/prolongate?refresh_token=<refresh_token>&access_token=<access_token>
Als Response bekommt man:
{
    "status" : true,
    "access_token" : <access_token>,
    "refresh_token" : <refresh_token>
}
Auf der Seite von Authorisierungsmodule gibt es dann folgende DB-Tabellen:

app_id	user_id	access_token	refresh_token	expires_at
3299	3243	NKFJD6FSK3	dsdcGJHG6_D	154228324235
3299	5432	SDKBkj7HK	DBJhBU7gi7	1542283400235
2348	23445	KFVNKJnkj78g	SBJbjs6sgvV	1542283400523

Das Authorisationsmodule hat alle notwendigen Informationen, wo und wer angemeldet ist. Das ermöglicht ein Logout von allen oder bestimmten Applikationen durch das Löschen von access_token und refresh_token.

• UPDATE table SET refresh_token = NULL, access_token = NULL WHERE user_id = 3243;

Offene Fragen:

• Wie oft und wie kann die Client-Applikation die Gültigkeit des Token prüefen?
• Wie soll das refresh_token funktionieren? Z.B. wenn der Benutzer ausgeloggt ist.
• Wie kann die Client-App feststellen, dass es um einen und den selben Benutzer geht? Z.B. nach dem Logout und erneuten Login.