214 lines
16 KiB
Markdown
214 lines
16 KiB
Markdown
Initialisierungs Studie nach Vorlage von Hermes-gibb
|
|
|
|
#### Zweck des Dokuments
|
|
Die Initialisierungsstudie bewertet Machbarkeit, Erfolgsaussichten und definiert erste Richtlinien für Projekte durch grundlegende Analysen und Bewertungen, um den Startpunkt festzustellen und potenzielle Risiken anzugehen.
|
|
|
|
#### Projektübersicht
|
|
| Name | Value |
|
|
| ----------------- | ------------------------------------------------------------- |
|
|
| **Status** | In Arbeit |
|
|
| **Projektname** | Raspydock |
|
|
| **Projektleiter** | Nadja Ehrengruber |
|
|
| **Auftraggeber** | Janik Wyder |
|
|
| **Autoren** | Florian Lehmeier, Nadja Ehrengruber, Janis Rölli |
|
|
| **Verteiler** | Florian Lehmeier, Nadja Ehrengruber, Janis Rölli, Janik Wyder |
|
|
|
|
#### Änderungskontrolle, Prüfung, Genehmigung
|
|
| Version | Datum | Beschreibung, Bemerkung | Name oder Rolle |
|
|
| ------- | ---------- | ----------------------- | --------------- |
|
|
| 0.1 | 13.02.2024 | Dokument erstellt | Nadja |
|
|
| | | | |
|
|
| | | | |
|
|
| | | | |
|
|
|
|
#### Glossar
|
|
| Begriff / Abkürzung | Bedeutung |
|
|
| ------------------- | --------- |
|
|
| | |
|
|
|
|
#### Referenzen
|
|
| Referenz | Titel, Quelle |
|
|
| -------- | ------------- |
|
|
| \[1\] | ~~keine~~ |
|
|
| \[2\] | ~~keine~~ |
|
|
| \[3\] | ~~keine~~ |
|
|
|
|
|
|
### Inhalt
|
|
- [1 - Situationsanalyse](#1---situationsanalyse)
|
|
- [1.1 - Ausgangslage](#11---ausgangslage)
|
|
- [1.2 - Stärken](#12---stärken)
|
|
- [1.3 - Schwächen](#13---schwächen)
|
|
- [2 - Ziele](#2---ziele)
|
|
- [2.1 - Rahmenbedingungen](#21---rahmenbedingungen)
|
|
- [2.2 - Abgrenzung](#22---abgrenzung)
|
|
- [3 - Liste der Stakeholder](#3---liste-der-stakeholder)
|
|
- [4 - Anforderungen](#4---anforderungen)
|
|
- [5 - Lösungsvarianten](#5---lösungsvarianten)
|
|
- [5.1 - Variantenübersicht](#51---variantenübersicht)
|
|
- [5.2 - Beschreibung der Varianten](#52---beschreibung-der-varianten)
|
|
- [6 - Bewertung der Varianten (Tabelle)](#6---bewertung-der-varianten-tabelle)
|
|
- [7 - Lösungsbeschreibung](#7---lösungsbeschreibung)
|
|
- [8 - Projektplanung](#8---projektplanung)
|
|
- [9 - Empfehlung](#9---empfehlung)
|
|
- [10 - Projektfreigabe](#10---projektfreigabe)
|
|
|
|
|
|
### 1 - Situationsanalyse
|
|
#### 1.1 - Ausgangslage
|
|
Das Hosten von Webseiten und Services erfordert viel Kapazität. Hardware, Know-How, Zeit und Geduld. Beispielsweise braucht das Hosting viel Speicherplatz, RAM und CPU-Leistung. Dies können sich nicht alle Firmen oder Einzelunternehmer leisten. Deswegen suchen sie nach Lösungen, wie sie auf eine einfache Weise ihre Webseite erstellen können. Am praktischsten ist es doch, wenn man sich gar nicht um das technische kümmern muss. Genau diese Erleichterung wollen wir unseren Kunden mit unserem Projekt bieten.
|
|
|
|
#### 1.2 - Stärken
|
|
Heutzutage gibt es eine Vielzahl von Stärken für Unternehmen oder Einzelunternehmer, die Webseiten und Services hosten möchten, ohne über umfangreiche Ressourcen oder technisches Know-how zu verfügen. Cloud-Plattformen wie AWS, Google Cloud und Microsoft Azure bieten skalierbare Hosting-Lösungen ohne hohe Hardwareinvestitionen. Website-Baukasten-Plattformen wie Wix und Squarespace ermöglichen das Erstellen ansprechender Webseiten ohne technische Vorkenntnisse. Managed Hosting-Services nehmen Unternehmen die technische Verwaltung ab. Automatisierung und DevOps-Praktiken vereinfachen die Bereitstellung und Verwaltung von Anwendungen. Die Unterstützung durch die Entwickler-Community bietet Zugang zu umfangreichen Ressourcen und Best Practices im Bereich Hosting.
|
|
|
|
Bei unserem Projekt sollten wir sicherstellen, dass einige Punkte nicht vernachlässigt werden. Dazu gehören die Benutzerfreundlichkeit, Zuverlässigkeit und Stabilität der Plattform sowie deren Skalierbarkeit und Sicherheit. Darüber hinaus sollten wir darauf achten, dass der Kundensupport und die Dokumentation weiterhin effektiv sind. Diese Aspekte sind entscheidend für den Erfolg und die Zufriedenheit unserer Kunden.
|
|
|
|
#### 1.3 - Schwächen
|
|
Es gibt an der heutigen Situation auch Schwachpunkte. Diese wollen wir mit unserem Projekt verbessern.
|
|
|
|
| Nr. | Name | Beschreibung |
|
|
| --- | --------------------------------- | ------------ |
|
|
| S1 | Komplexität und technische Hürden | Viele Unternehmen und Einzelunternehmer könnten Schwierigkeiten haben, die technischen Anforderungen und Komplexitäten des Webhostings zu bewältigen. |
|
|
| S2 | Hohe Kosten | Die Einrichtung und Wartung einer Hosting-Infrastruktur kann kostspielig sein, insbesondere für Unternehmen mit begrenzten finanziellen Ressourcen. Dies können wir gut umgehen, da Janis die benötigte Hardware bereits besitzt. |
|
|
| S3 | Sicherheitsrisiken | Hosting-Infrastrukturen können anfällig für Sicherheitsbedrohungen wie Hacking und Datenverlust sein, insbesondere wenn sie nicht angemessen geschützt und gewartet werden. Darauf werden wir achtgeben, indem wir zum Beispiel von der Schule aus per VPN arbeiten werden. |
|
|
| S4 | Zeit- und Ressourcenaufwand | Die Einrichtung und Verwaltung einer Hosting-Infrastruktur erfordert Zeit und Ressourcen, die für Unternehmen und Einzelunternehmer möglicherweise knapp sind. Dies kann dazu führen, dass wichtige Ressourcen von anderen geschäftlichen Aufgaben abgezogen werden müssen, was die Effizienz und Produktivität beeinträchtigen kann. In diese Gefahr laufen wir nicht, da unsere Kernaufgabe das Projekt ist. Wir haben keine anderen geschäftlichen Aufgaben, bei welchen wir Zeit und Ressourcen verlieren könnten. |
|
|
|
|
|
|
### 2 - Ziele
|
|
**Muss-Ziele**
|
|
Im Folgenden beschreiben wir die Muss-Ziele unseres Projektes. Diese wollen wir unbedingt erreichen.
|
|
|
|
| Nr. | Beschreibung des Muss-Ziels | Behobener Schwachpunkt |
|
|
| --- | --------------------------- | ---------------------- |
|
|
| MZ1 | Möglichst lange Erhaltung der Hardware durch sorgfältigen und professionellen Umgang damit. | S2: Hohe Kosten<br><br>Es werden zusätzliche Kosten vermieden, da wir keine neue Hardware kaufen müssen. |
|
|
| MZ2 | Bis zur Kalenderwoche 22 soll eine benutzerfreundliche Website-Baukasten-Plattform implementiert werden, die es auch technisch weniger versierten Benutzern ermöglicht, ansprechende Webseiten zu erstellen. | S1: Komplexität und technische Hürden<br><br>Durch das bereits vorhandene Know-How und Recherche im Internet, können wir die benutzerfreundliche Plattform bereitstellen. |
|
|
| MZ3 | Gewährleisten der Sicherheit während des ganzen Projekts durch VPN-Verbindungen und Einhalten der Sicherheitsrichtlinien. | S3: Sicherheitsrisiken<br><br>Durch unsere Massnahmen wird die Sicherheit gewährleistet. |
|
|
| MZ4 | Implementierung einer automatisierten Hosting-Infrastruktur-Management-Lösung bis Kalenderwoche 22, die das Hosting von Websites und Services übernimmt, um den Aufwand für unsere Kunden zu reduzieren | S4: Zeit- und Ressourcenaufwand<br><br>Durch unsere Lösung erleichtern wir den Kunden die Arbeit und wir können uns ganz darauf konzentrieren, ohne daneben Zeit und Ressourcen an anderen Orten zu verlieren. |
|
|
| MZ5 | Erstellung und Abgabe aller Dokumente sowie die Vorbereitung und Haltung der Präsentation des Moduls 306. Parallel soll das Modul 300 bearbeitet werden. | |
|
|
|
|
**Kann-Ziele**
|
|
Wir haben noch einige Ziele formuliert, die wir anstreben werden, sofern wir mit den Muss-Zielen schnell vorankommen und noch verbleibende Zeit haben werden.
|
|
|
|
| Nr. | Beschreibung des optionalen Ziels |
|
|
| --- | --------------------------------- |
|
|
| OZ1 | Erstellung von Dokumentationen und Schulungsmaterial zu unserer Umgebung als PDF für die Kunden bis Kalenderwoche 25. |
|
|
| OZ2 | Integration von Analyse- und Reporting-Tools bis Kalenderwoche 22, um den Nutzern detaillierte Einblicke in die Leistung ihrer gehosteten Webseiten und Services zu bieten. |
|
|
| OZ3 | Einführung von Zwei-Faktor-Authentifizierung für unsere Plattform bis Kalenderwoche 22, um die Sicherheit zu erhöhen. |
|
|
|
|
#### 2.1 - Rahmenbedingungen
|
|
Das Projekt läuft im Rahmen des Moduls 306 der IET-gibb ab. Wir arbeiten während dem Unterricht am Dienstagmorgen daran und bei Bedarf zuhause. Die Hardware befindet sich bei Janis. Wenn wir von einem anderen Ort daran arbeiten, greifen wir per VPN darauf zu. Ausserdem organisieren wir und mündlich oder schriftlich über Teams im Projektteam. Wir sind auch immer wieder mit unserem Lehrer Gerhard Beutler im Austausch, wer als Ratgeber und Bewerter unseres Projekts tätig ist. Die zeitlichen Rahmenbedingungen sind der untenstehenden Tabelle zu entnehmen.
|
|
|
|
| KW | Was |
|
|
| ------- | --------------------------------------------------------------- |
|
|
| 10 | Abschluss der Initialisierungsphase |
|
|
| 12 | Abschluss der Konzeptphase |
|
|
| 20 | Abschluss der Realisierungsphase |
|
|
| 22 | Abschluss der Einführungsphase |
|
|
| 23 | Abschluss des Schlussberichts und Vorbereitung der Präsentation |
|
|
| 24 / 25 | Präsentation des Projekts |
|
|
| 26 | Reserve |
|
|
|
|
#### 2.2 - Abgrenzung
|
|
|
|
|
|
```
|
|
Wo sind die Grenzen Ihres Projektes? Was alles wird durch Ihr Vorhaben explizit nicht abgedeckt?
|
|
```
|
|
|
|
|
|
### 3 - Liste der Stakeholder
|
|
Von unserem Projekt sind die Personen betroffen, die in der Tabelle aufgeführt sind. Daneben ist noch zu lesen, welche Rolle sie in unserem Projekt haben.
|
|
|
|
| Wer | Rolle |
|
|
| ----------------- | ----------------------------- |
|
|
| Florian Lehmeier | Projektteammitglied |
|
|
| Janis Rölli | Projektteammitglied |
|
|
| Nadja Ehrengruber | Projektleiterin |
|
|
| Janik Wyder | Auftraggeber |
|
|
| Gerhard Beutler | Berater, Bewerter, Lehrperson |
|
|
|
|
Florian, Janis und Nadja bilden das Projektteam, Nadja wirkt als Projektleiterin. Gemeinsam wollen wir das Projekt erfolgreich durchführen. Wir sind immer wieder mit dem Auftraggeber in Kontakt. Er hat unser Projekt bereits freigegeben und wir werden ihm ebenfalls die Studie zur Kontrolle und Unterschrift vorlegen. Anschliessend werden wir die Studie an Herrn Beutler abgeben, um von ihm eine Rückmeldung zu erhalten.
|
|
|
|
|
|
### 4 - Anforderungen
|
|
| Nr. | Anforderung | Bearbeitetes Ziel |
|
|
| --- | ----------- | ----------------- |
|
|
| A1 | Regelmässige Wartung der Hardwarekomponenten, also regelmäßige Überprüfungen, Reinigungen und Aktualisierungen. | MZ1: Verlängerung der Lebensdauer der Hardware |
|
|
| A2 | Schulung des Personals in Bezug auf den sachgemäßen Umgang mit der Hardware und die Durchführung von Wartungsmaßnahmen. | MZ1: Verlängerung der Lebensdauer der Hardware |
|
|
| A3 | Regelmäßige Aktualisierung der Firmware und Treiber der Hardwarekomponenten, um die Leistung und Sicherheit zu verbessern und Kompatibilitätsprobleme zu minimieren | MZ1: Verlängerung der Lebensdauer der Hardware |
|
|
| A4 | Entwicklung eines einfach bedienbaren Systems für das Erstellen von Websites. Es soll auch von technisch weniger versierten Benutzern verstanden werden. | MZ2: Implementierung einer benutzerfreundlichen Website-Baukasten-Plattform |
|
|
| A5 | Integration einer guten Dokumentation, welche die Benutzer anleitet. | OZ1: Implementierung einer benutzerfreundlichen Website-Baukasten-Plattform |
|
|
| A6 | Einrichtung eines Virtual Private Network (VPN) für sichere Verbindungen und den Schutz vor externen Bedrohungen. | MZ3: Gewährleistung der Sicherheit während des gesamten Projekts |
|
|
| A7 | Regelmäßige Sicherheitsaudits und Kontrollen, um potenzielle Schwachstellen zu identifizieren und zu beheben. | MZ3: Gewährleistung der Sicherheit während des gesamten Projekts |
|
|
| A8 | Entwicklung einer benutzerfreundlichen Oberfläche für das Management und die Überwachung von Hosting-Ressourcen, einschließlich der automatischen Skalierung und Lastverteilung. | MZ4: Implementierung einer automatisierten Hosting-Infrastruktur-Management-Lösung |
|
|
| A9 | Ermöglichung der Verwaltung der bereitgestellten Services und Webseiten für den Kunden. | MZ4: Implementierung einer automatisierten Hosting-Infrastruktur-Management-Lösung |
|
|
|
|
### 5 - Lösungsvarianten
|
|
#### 5.1 - Variantenübersicht
|
|
|
|
|
|
```
|
|
Bis hierher haben Sie sich viele Gedanken über das eigentliche Problem und die Anforderungen an seine Lösung gemacht.
|
|
Nun ist es wichtig, dass Sie sich von Ihrer (wahrscheinlich ja schon vorhandenen) Lösungsidee distanzieren, um andere Alternativen in Betracht ziehen zu können.
|
|
|
|
Lassen Sie Ihrer Phantasie einen Spielraum und überlegen Sie sich echte Varianten für eine Lösung der Aufgabestellung.
|
|
In der Regel lassen sich mindestens drei verschiedene Lösungsvarianten finden.
|
|
```
|
|
|
|
#### 5.2 - Beschreibung der Varianten
|
|
|
|
|
|
```
|
|
Beschreiben Sie hier die gefundenen Lösungsvarianten so genau, dass auch eine aussenstehende Person mit wenig technischem Sachverständnis den weiter unten gefällten Entscheid nachvollziehen kann.
|
|
```
|
|
|
|
|
|
### 6 - Bewertung der Varianten (Tabelle)
|
|
|
|
|
|
```
|
|
Führen Sie hier Ihren möglichst objektiven Variantenentscheid durch.
|
|
Oft ist die Lösung, welche schon von Anfang an favorisiert wurde, nicht die beste.
|
|
|
|
Einen nachvollziehbaren Entscheid erreicht man z.B. mit eine Tabelle, in welcher die einzelnen Varianten einer Liste von (gewichteten) Kriterien gegenübergestellt werden (siehe auch AB 306.08).
|
|
```
|
|
|
|
|
|
### 7 - Lösungsbeschreibung
|
|
|
|
|
|
```
|
|
Beschreiben Sie nun die gefundene Lösungsvariante in allen ihren Details.
|
|
Aus welchen Komponenten besteht die Lösung (evtl. System-Skizze einbauen).
|
|
|
|
Überprüfen Sie zum Schluss anhand einer Tabelle, ob durch die gewählte Lösung auch wirklich alle Anforderungen abdecken.
|
|
```
|
|
|
|
|
|
### 8 - Projektplanung
|
|
|
|
|
|
```
|
|
Erstellen Sie hier einen (vorerst noch groben) Zeitplan für die Durchführung des Projektes (mindestens Dauer und Abschluss der einzelnen Phasen sowie wichtigste Meilensteine).
|
|
|
|
Verwenden Sie dazu eine Excel-Tabelle oder ein Gantt-Diagramm.
|
|
```
|
|
|
|
|
|
### 9 - Empfehlung
|
|
|
|
|
|
```
|
|
Empfehlen Sie hier dem Auftraggeber, den Projektentscheid zu Gunsten der ausgewählten Variante zu treffen und das Projekt freizugeben.
|
|
```
|
|
|
|
|
|
### 10 - Projektfreigabe
|
|
**Hiermit bestätigt der Auftraggeber die Freigabe des Projekts:**
|
|
|
|
> Unterschrift Auftraggeber erfolgte: \<Ort>, \<Datum>
|
|
|
|
> Unterschrift Projektleitering erfolgte: \<Ort>, \<Datum>
|
|
|
|
---
|