Extranet Projekt
Im Fach Web Engineering erhielten wir den Auftrag ein Extranet zu
designen und einen Teil davon als Prototyp umzusetzen. Adrian Fischer
und Gisela Dymorz entschieden sich die Arbeit als Gruppe durchzuführen.
Diese Seite soll ein Überblick unseres Extranets geben und was wir im
Prototyp realisieren möchten.
Bewertungskriterien für den Prototyp
- Extranet home page
- Site structure and navigation
- News
- Extranet Content
Erfahrungsbericht
Damit diese Seite nicht zu lang wird, ist unser Erfahrungsbericht unter
DevTeam09Erfahrungsbericht einsehbar.
Logins
Login | Passwort | Zugriffsrechte |
Martin Keller | mkdrupal | newsadmin |
Tim Burger | tbdrupal | project manager / Fiktives Unternehmen / Avireal / Siemens VDO |
Anita Tobler | atdrupal | project member / Siemens VDO |
Jens Hefti | jhdrupal | project member / Siemens VDO |
Tina Gutmann | tgdrupal | project member / Migros |
siteadmin auf Anfrage: gdymorz@hsz-t.ch oder afische2@hsz-t.ch
Unser fiktives Unternehmen
Um bestimmen zu können, wie eine Extranet-Seite aussehen soll und was
sie können soll, haben wir uns ein fiktives Unternehmen vorgestellt.
Unser Unternehmen führt Projekte für und mit Kunden durch. Diese Kunden
möchten sich selbständig über den Stand der Projekte informieren
können, ihre Informationen an einem zentralen Ort ablegen und so mit
dem Projektteam in Kontakt sein. Dafür soll ein Extranet erstellt
werden.
Grob-Beschreibung des Extranet's
Um
den Geschäftszweck des Unternehmens erfüllen zu können, wird ein
zentrales Ablagesystem für Dokumente und ein Aufgabenbrett, mit
Zuweisung der Aufgaben an einen Projektleiter oder -mitarbeiter
benötigt. Die Geschäftsleitung möchte über dieses Instrument Kunden
über Entwicklungen im Unternehmen auf dem laufenden halten und sehen,
welche Kunden sich aktiv an ihren eigenen Projekten beteiligen.
Abgrenzungen
Business Goals
Die folgende Liste zeigt die Ziele, welche das Unternehmen mit dem neuen Extranet erreichen möchte:
- Produktivitätssteigerung intern und bei der Zusammenarbeit mit dem Kunden.
- Steigerung der Übersichtlichkeit in einem Projekt.
- Kommunikationssteigerung zwischen Kunden und Projekt-Team bzw. im Projektteam intern.
Zielgruppe
Das Extranet hat folgende Zielgruppen:
- Kunden
- Projektleiter
- Projektmitarbeiter
Über Auswertungen, welche aus den Zugriffen gemacht werden, kann sich
die Geschäftsleitung über die Aktivität ihrer Kunden und Mitarbeiter
informieren.
Success Metrics / Erfolgskriterien
Um den Erfolg des Extranets messen zu können werden folgende Erfolgskriterien festgelegt:
- Kunden finden ohne Hilfe und ohne Einführung sämtliche für ihre Projekte relevanten Daten.
- Projektmitglieder suchen nur im Extranet nach Informationen zu den Projekten.
User Stories
Ein Auszug, was unsere Benutzer und Kunden erwarten:
- Übersicht aller aktuellen Projektdokumente
- Eintragen und Zuweisen von Aufgaben
- Projektarchiv
- Information was im Unternehmen so läuft
Content Inventory
Um
unseren Content einzelnen Kunden zur Ansicht freigeben zu können,
müssen wir mit Categories arbeiten. In allen aufgeführten Content-Typen
ist Customer die Categorie für den Zugriff.
Projekte
Hauptinhalt des Extranets sind die Informationen, Aufgaben und
Dokumente zu den Projekten der Kunden. Diese Inhalte wachsen und ändern
sich mit dem Fortschritt der Projekte laufend, nur so macht das
Extranet in diesem Fall überhaupt Sinn.
Da diese Informationen erst mit dem Betrieb des Extranets wachsen,
werden wir einige Test-Daten im Prototyp eintragen, um ein Gefühl zu
vermitteln, wie es funktioniert.
Ein Projekt besteht aus folgenden Felder --> Content Type = Projekt:
- From date --> Startdatum für das Projekt (Muss-Feld)
- To date --> Enddatum für das Projekt (Muss-Feld)
- Title --> Projektbezeichnung (Muss-Feld)
- Short Description
- Customer --> Kunde, zu welchem das Projekt gehört (Muss-Feld)
- Description
- File attachments
Aufgabenliste / Aufgaben
Eine Aufgabenliste besteht aus verschiedenen Aufgaben. Eine Aufgabe
besteht aus folgenden Feldern --> Content Type = Aufgabe:
- Title (Muss-Feld)
- Categorie (Muss-Feld)
- Customer --> Kunde, zu welchem die Aufgabe gehört (Muss-Feld)
- Task state --> New, Finished, Suspended, Working (Muss-Feld)
- Body
- Due on --> Fälligkeit
- Responsible --> Zuständige Person (Muss-Feld)
- Project --> Projekt, zu welchem die Aufgabe gehört
- File attachments
Neuigkeiten
Die Neuigkeiten sind vor allem für die Geschäftsleitung von Interesse,
da so sämtliche Mitarbeiter und Kunden erreicht werden können. Da das
Unternehmen nur fikiv ist, werden wir auch hier einige Test-Daten
eintragen.
- From date --> Startdatum für das Projekt (Muss-Feld)
- To date --> Enddatum für das Projekt (Muss-Feld)
- Titel
- Customer --> Kunden, welche die News sehen können
- Short text
- Long text
- File attachments
Spezifikation
Unsere erste Vision kann man unter
DevTeam09Vision
nachlesen. Leider stellten wir nach einiger Zeit fest, dass wir da
etwas viel von Drupal wollen, somit mussten wir unsere Spezifikation
anpassen. Die Verschachtelung des Contents haben wir gestrichen, da
niemand so richtig weiss wie das Umsetzen von verschachteltem Content
in Drupal funktioniert (Gemäss den Informationen, welche wir im
Internet gefunden haben).
Rollen
siteadmin
Kann alles bearbeiten. Er ist auch zuständig für die Administration der Kunden und der Benutzer.
authenticated user
Jede andere Rolle ist automatisch auch authenticated user:
- node module
- upload module
- upload files
- view uploaded files
project member
- node module
- edit project content
- edit own project content
- create task content
- edit own task content
- edit task content
project manager
- node module
- create project content
- edit project content
- edit own project content
- create task content
- edit own task content
- edit task content
news administrator
- node module
- create news content
- edit news content
- edit own news content
Weitere Rollen
Pro Kunde
wird eine weitere Rolle angelegt. Über diese Rolle wird gesteuert,
welche Einträge ein User sehen kann oder nicht. Jeder User gehört zu
einer der obenstehenden Rollen und zu einem oder mehreren Kunden. Die
Kunden-Rollen sind nur für den Zugriff auf die einzelnen Kundenbereiche
nötig!
Zusätzlich gibt es noch die Rolle "all companies". Diese Rolle
besteht um den Administrationsaufwand für Benutzer, welche alle Kunden
bearbeiten müssen, möglichst klein zu halten. Für diese Kunden reicht
es beim Hinzufügen eines neuen Kunden diese Rolle anzupassen. Auf diese
Weise wird die Fehleranfälligkeit der Konfiguration vermindert.
Die Steuerung der Kunden erfolgt über die Categorie Customers
(Access control by taxonomy) und den Role based privileges. Bei den
Role based privileges wir hinterlegt, welche Rolle auf welches Wort der
Categorie zugriff hat.
Navigationskonzept
Unsere Navigation soll möglichst einfach gehalten werden und einen raschen Zugriff auf die neusten Einträge bieten.
Linker Bereich
Anzeige der Navigation. Die Navigation hat für Benutzer folgende Struktur:
- Home
- News
- Projects
- Tasks
- Create content
- Recent posts
- My account
- Log out
Die Menü-Einträge News, News archive, Project, Project archive, Task
und Task archive führen zu einer Liste der entsprechenden Content-Type.
Weitere Informationen unter Mittlerer Bereich.
Rechter Bereich
Im rechten
Bereich des Extranets wird eine News Übersicht mit den neusten drei
News dargestellt. Klickt man auf den Titel gelangt man zum kompletten
News Eintrag. Es werden nur News angzeigt, welche für den Benutzer
bestimmt sind und ihm über die Rollen zugewiesen sind.
Über den more Link am unteren Ende der Liste gelangt man auf die Übersichtsseite aller News.
Mittlerer Bereich
Die
Menü-Einträge News, Project, und Task führen zu einer Liste der aktiven
Einträge des entsprechenden Content-Types. Dabei gilt folgende Regel:
- News --> News Einträge, ein Startdatum kleiner heute und ein Enddatum grösser/gleich heute haben.
- Project --> Project Einträge, ein Startdatum kleiner heute und ein Enddatum grösser/gleich heute haben.
- Task --> Task Einträge, welche Neu oder In Arbeit sind (New / Working).
Bei den Task's ist es zusätzlich möglich die Tasks zu Filtern nach:
Die Sortierung kann nach Title oder Due on selber gesetzt
werden. Due on ist Standard, damit der zuerst zu erledigende Eintrag zu
oberst ist.
Archive
Im Archiv befinden sich je nach Content-Type eine etwas andere Zusammenstellung:
- News archive --> News Einträge, welche ein Enddatum haben, welches in der Vergangenheit liegt.
- Project archive --> Project Einträge, welche ein Enddatum haben, welches in der Vergangenheit liegt.
- Task archive --> Task Einträge, welche Beendet oder Sistiert sind (Finished / Suspended).
Home
Wir streben einen möglichst
raschen Zugriff auf die aktuellen Einträge an, was wir mit der Home
Seite umsetzen.
Auf der Home Seite (welches auch die Startseite ist), wird eine Liste
der aktuellsten 10 Projekte angzeigt. Ausserdem ist eine Liste der
offenen Task's sichtbar. Von dieser Seite aus kann gelangt man auf die
Detail-Ansichten der Einträge.
Prototyp
Wir legen unser Augenmerk beim Prototypen auf folgende Punkte:
- Benutzerverwaltung --> Da dies der zentrale Teil unseres Projekts ist
- News --> Da wir dies in den Kriterien ausgewählt haben
- Abbildung der gesamten Struktur --> damit die Navigation sichtbar wird
Es wird jedoch kaum möglich sein, mit einem angemessenen Aufwand die
gesamte Funtkionalität abzubilden. Das Forum, welches wir zuerst
ebenfalls einbinden wollten, liessen wir weg. Wir werden uns für den
Content daher auf die Bereiche konzentrieren, welche wir auch wirklich
im Prototyp implementieren. Sollte es nicht möglich sein mit
bestehenden Modulen die Funktionalität abzudecken, werden wir unsere
zentralen Prototyp-Punkte und die Spezifikation verändern, da es in
diesem Rahmen keinen Sinn macht, selbständig ganze Module zu
programmieren.
Fazit
Unsere Anforderung würden wir
nicht mit Drupal umsetzen. Drupal ist dafür einfach nicht gemacht.
Schon beim Einrichten mehrere Benutzergruppen und ihren Berechtigungen
kommt Drupal rasch an seine Grenzen und wird unübersichtlich.
Vielleicht hätten uns die einen oder anderen Module die Arbeit
erleichtert, doch wir haben vermutlich nicht alle diese Module
gefunden.
Drupal ist gut für eine Seite, welche einfache Texte, Anhänge
und auch Foren publizieren soll. Drupal eignet sich wenig für Webs, in
denen sensible Kundendaten gespeichert sind, da für eine umfangreiche
Funktionalität diverse Module von verschiedenen Entwicklern verwendet
werden müssen.