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

  1. Extranet home page
  2. Site structure and navigation
  3. News
  4. 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
    • access content
  • 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
    • News archive
  • Projects
    • Project archive
  • Tasks
    • Task archive
  • 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:

  • Project
  • Responsible
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.

This topic: Webeng > WebHome > WebengFS08 > GruppenFS08 > DevTeam09
History: r13 - 02 Jun 2008 - 18:25:44 - GiselaDymorz
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback