1 17.7.2003 21:33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten. Architektur

17.7.2003 21:33 Architektur Moderner Internet Applikationen – VorgehensmodellCopyright ©2003 Christian Donner. Alle Rechte vorbehalten.

1

Architektur Moderner

Internet Applikationen

22.-24.4.2004 TU Wien/Ausseninstitut

Ein erprobtes Vorgehensmodell

DI Christian Donnercd (at) donners.com


2

EinleitungEinleitung

Dieses Vorgehensmodell ist in der Praxis entstanden und definiert eine Vorgangsweise, mit der selbst “Worst Case” Szenarien souverän bewerkstelligt werden können, wie z.B. Auftraggeber mit besonders langsamen Entscheidungsfindungsprozessen, besonders föderalistischen Organisationsformen mit vielen Entscheidungsträgern, etc.

In der Regel werden einzelne Teile jedoch weggelassen, je nach Reifegrad der Vertragspartner und des Projektes.


3

Zusammensetzung des TeamsZusammensetzung des Teams

Die folgenden Projektrollen sind typischerweise vertreten:

Projektsponsoren oder LenkungsausschussProjektleiterBusiness Analyst, OrganisatorSolution Architect“Client Partner” oder Account ManagerInformation ArchitectWeb DesignerQA LeadSoftwareentwicklerTesterConfiguration Manager


4

Aufgaben der ProjektsponsorenAufgaben der Projektsponsoren

Typischweise Vertreter des Managements von Auftraggeber und Auftragnehmer

Klassische Rollen:Bereitstellung von Budget und ResourcenBuy-In bei Endbenutzern sicherstellenDefinition der ProjektzieleLetzte Kontrollinstanz für ProjektfortschrittVermittlung bei Krisen, die von niedrigeren Ebenen eskaliert wurdenEntscheidungsinstanz bei Budget- und Terminüberschreitungen


5

Aufgaben des ProjektAufgaben des Projektleitersleiters

Erstellung und Wartung des Projektplanes

Statusberichte intern und extern

Krisenidentifikation und -management

Planung und Durchführung von Meetings

Kick-Off und Projektende

Information und Kommunikation

Laufender Soll-Ist Vergleich und regelnder Eingriff bei Abweichungen


6

Aufgaben des Solution ArchitectAufgaben des Solution Architect

Festlegung der Hard- und Softwareplattform

Erstellung des AnwendungsdesignsDatenbankdesignApplikationsdesignSchnittstellen

Leitung der EntwicklungsphaseMentor und Anlaufstelle für SoftwareentwicklerArbeitszuteilung und Abnahme von ModulenFehlermanagement (Defects)

Code Reviews

Produktionsstart


7

Aufgaben des Business AnalystAufgaben des Business Analyst

Abhaltung von Workshops zur Anforderungsanalyse

Erstellung des Pflichtenhefts

Training der Benutzer


8

Aufgaben des Client PartnerAufgaben des Client Partner

Manchmal ist es notwendig, dem Auftraggeber eine Person zur Seite zu stellen, die nicht direkt mit der Projektimplementierung befasst ist und sich mit einem Problem daher mit mehr Distanz befassen kann

Dies ist nur bei sehr großen Projekten eine Vollzeitposition


9

Aufgaben des Information ArchitectAufgaben des Information Architect

Abhaltung von Workshops zur Analyse und Definition von Inhalten und Inhaltsstrukturen

Gestaltung der Benutzerschnittstelle

Erstellung von Seitenschemata

Erstellung des Dokuments “Information Architecture Recommendations”

Zusammenarbeit mit dem Designer zur Gestaltung des graphischen Auftritts


10

Aufgaben des WebdesignersAufgaben des Webdesigners

Erstellung eines StyleguidesFarbenSchriftarten und –größenBildgrößenGraphisches Layout

Erstellung von “Design Comps”, graphischen Elementen und Animationen


11

Aufgaben des QA LeadAufgaben des QA Lead

Erstellung des Testplans

Durchführung von Tests

Definition des Fehlerbehebungsprozesses

Konfiguration von Tools


12

Aufgaben des Configuration ManagerAufgaben des Configuration Manager

Durchführung von ReleasesZusammenfassung von Änderungen zu einer ReleasePhysische Durchführung, evtl. TeilautomatisiertRelease-Dokumentation

Verantwortlich für Versionskontrolle


13

55-Stufiges Vorgehensmodell-Stufiges Vorgehensmodell

Workshops

IA Anforderungen

“Focus Groups”

ReviewprozessSchematische

Diagramme

Pflichtenheft

SchematischeSeiten-

beschreibung

Informationsanalyse

Funktionale AnalyseHardware- und

Software-anforderungen

TechnischesDesign

Technische Analyse

Entwicklung Test Implementierung

Anforderungsanalyse

Umsetzung

Entwicklungsplan

Reviewprozess

ReviewprozessReviewprozess


14

Phase 1 - AnforderunsanalysePhase 1 - Anforderunsanalyse

Zumindest eine Person im Team (Projektleiter, Business Analyst oder Information Architect) muss geschult und erfahren im Moderieren von Workshops sein.

Internet Projekte erfordern, mehr als klassische IT Projekte, ein striktes Vorgehen in dieser Phase, weil der Auftraggeber oft nur eine vage oder gar keine Vorstellung vom Endprodukt hat.

Daher müssen alle Workshops zeitlich begrenzt sein (“time-boxed”) und ein klares Ziel haben.

Die Ergebnisse der Anforderungsanalye fließen direkt und teilweise parallel in alle 3 folgenden Phasen.

Federführend sind der Business Analyst und der Information Architekt.


15

WorkshopWorkshop – – Business Goals, User RolesBusiness Goals, User Roles,, User Needs User Needs

Aktivität Business Goals, User Roles and User Needs Activity

Erläuterung In diesen Workshops (oft sind mehr als eines notwendig) werden die Ziele erforscht, die der Auftraggeber mit dem Projekt erreichen möchte, und häufig auch quantifizierbare Kriterien zur Messung des Grades der Zielerreichung definiert (z.B. X% mehr registrierte Benutzer, Y% mehr Onlineumsatz etc).Weiters werden die unterschiedlichen Rollen der Endbenutzer definiert und die Bedürfnisse, die sie in diesen Rollen haben.

Zweck Das Ziel dieser Aktivität ist die Definition von Benutzergruppen und ihrer Bedürfnisse; außerdem werden etwaige “Business Goals“ bestimmt und auf Messbarkeit untersucht.


16

Workshop – Content LebenszyklusWorkshop – Content Lebenszyklus

Aktivität Content Lifecycle

Erklärung Dieses Workshop ist nötig, um den Publikationsprozeß beim Auftraggeber zu definieren. Die Arten von Inhalten, die publiziert werden, ordnet man Datentypen (Assets) im Content Management System zu und überlegt, wie sich der Publikationsprozeß im Content Management System abbilden läßt.

Zweck Diese Aktivität verschafft Einblick in den Publikationsprozeß, z.B. Die Häufigkeit von Updates, Wachstumgeschwindigkeit der Daten und die beteiligten Personen und Rollen.

Wie entstehen Inhalte, wie gelangen sie auf den Website und wann und wie verschwinden sie wieder?


17

AnalyseAnalyse – Feature – Featuress/Fun/Funkktiontionenen

Aktivität Features/Funktionen-Analyse

Erläuterung Als Vorbereitung für diese Aktivität wird eine vollständige List von Funktionen erstellt, die die Benutzer zur Erfüllung ihrer Bedürfnisse benötigen. Danach wird die bestehende Anwendung (falls es eine gibt) aus diesen Gesichtspunkten nach Problembereichen und Hindernissen untersucht. Aus dem Mitbewerber-Audit werden potentielle Lösungswege eingebracht.Die Ergebnisse dieses Prozesses werden in das IA Anforderungsdokument eingearbeitet und in einem Workshop mit dem Auftraggeber besprochen.

Zweck Formulierung von Empfehlungen bezüglich angebotener Funktionen.


18

Phase 2 - InformationsanalysePhase 2 - Informationsanalyse

Diese Phase läuft teilweise parallel mit der Anforderungsanalyse und der Funktionalen Analyse. Teilergebnisse fließen zurück in die Workshops.

Federführend ist der Information Architekt

Ergebnis dieser Aktivität sind folgende Dokumente:IA Anforderungsdocument (“Information Architecture Recommendations”)Mitbewerber-AuditHeuristische EvaluierungSite Plan (site map)Schematische Seitendiagramme


19

Dokument Dokument – – IA AnforderungenIA Anforderungen

Aktivität IA Anforderungsdokument

Erklärung Die IA Anforderungen enthalten Ziele, Benutzerrollen und –bedürfnisse sowie Empfehlungen umgelegt auf jede einzelne Seite der Web-Applikation.

Zweck Ziel dieses Dokuments ist die grobe Indentifikation der Navigationsstrukturen und der Features und Funktionen der Applikation zu dem Zweck der Abstimmung und mit dem Auftraggeber. Der Auftraggeber wird das Dokument einem Review-Prozess unterziehen und beide Parteien unterschreiben. Diese Dokument dient dann als Basis für das Pflichtenheft.


20

DokumentDokument – Heuristi – Heuristischesche Evalu Evaluierungierung

Aktivität Heuristische Evaluierung

Beschreibung Die heuristische Evaluierung ist eine Beurteilung der gegenwärtigen Anwendung, basierend auf dem Stand der Technik. Das Ergebnis wird üblicherweise als Teil des Mitbewerber-Audits dokumentiert.

Zweck Ziel dieses Schrittes ist die Identifikation von groben Problemen mit der gegenwärtigen Anwendung in Bezug auf Bedienbarkeit und Funktionalität, damit diese Probleme für die zu entwickelnde Anwendung von vornherein ausgeschlossen werden können.


21

DokumentDokument – – MitbewerberMitbewerber Audit Audit

Aktivität Mitbewerber-Audit

Beschreibung Das Mitbewerber-Audit ist eine Beurteilung von Web Sites der wichtigsten Mitbewerber des Auftraggebers auf der Ebene Features-Funktionen und enthält Empfehlungen zur Verbesserung der Wettbewerbsfähigkeit des Auftraggebers.

Zweck Ziel dieses Schrittes ist, Idee zu erhalten, wie Mitbewerber bestimmte Fragestellungen gelöst haben. Dies ist wichtig, um die eigene Anwendung wettbewerbsfähig gestalten zu können.


22

Workshop Workshop – – Validierung von Navigation und Inhalt Validierung von Navigation und Inhalt

Aktivität Validierung der Navigation und des Inhaltsangebots

Erklärung Dieses Workshop wird interaktiv abgehalten. Alle Inhalte werden auf Post-It Zetteln notiert. Auf der Tafel befindet sich eine Abbildung der Navigationstruktur. Jeder Zettel wird auf der Tafel einer Seite zugeordnet. Falls für eine Art von Inhalt kein Platz gefunden wird, verändert man die Navigationstruktur oder, falls nicht wichtig genug, nimmt den Inhalt gänzlich aus der Anwendung.

Dieses Workshop wird üblicherweise in 4 bis 6 jeweils 3-stündigen Sessions abgewickelt.

Zweck Ziel ist, ein Zuhause für alle Inhalte zu finden, die auf der Website angeboten werden, überflüssige Inhalte zu identifizieren und zu entfernen sowie die Navigationsstruktur möglichst frühzeitig im Projekt finalisieren zu können.


23

DokumentDokument – Site Map – Site Map

Aktivität Site Map

Erklärung Diese Grafik stellt Inhalte, Navigationspfade und Beziehungen zwischen einzelnen Seiten dar.

Zweck Visualisierung von Inhalten und der Position von einzelnen Seiten in der gesamten Anwendung. Die Seiten sollten bereits die endgültigen Namen tragen.


24

Beispiel - Beispiel - Site Site MapMap


25

DokumentDokument – Style Guide – Style Guide

Aktivität Style Guide

Erklärung Dieses Dokument enthält die Spezifikationen für Grafiken und HTML Element.

Zweck Zweck ist die Sicherstellung einer einheitlichen Umsetzung von Grafiken und HTML. Das Dokument ist besonders wichtig, wenn projektfremde Personen an der Entwicklung der Grafiken und des HTML Code arbeiten.


26

Style Guide. . . . Style Guide. . . .

Beispiel - Beispiel - Style GuideStyle Guide


27

UmsetzungUmsetzung – Gra – Graffiischesche Produ Produkktiontion

Aktivität Grafische Produktion

Erklärung Erstellung der Grafiken für die Anwendung.

Zweck Softwareentwickler brauchen die Grafiken, wenn die Programmierung der Seiten beginnt.


28

UmsetzungUmsetzung – HTM – HTMLL

Aktivität Erstellung des HTML Code

Erklärung Diese Aktivität wird manchmal aus der eigentlichen Softwareentwicklungsphase herausgelöst – z.B. weil der HTML von Designern erstellt werden soll und nicht von Softwareentwicklern.

Diese Praxis ist jedoch umstritten, weil die spätere Integration solcherart erstellten HTML Codes in eine dynamsche Webapplikation problematisch ist.

Zweck Erstellung von HTML Seiten. Die Seiten können entweder mit funktionierenden Navigationselementen ausgestattet sein (“click-through demo”) oder nur das Layout der Seite enthalten (rein statisch).


29

Phase 3 - Funktionale AnalysePhase 3 - Funktionale Analyse

Diese Phase läuft teilweise parallel mit der Analyse der Informationsarchitektur

Federführend ist der Business Analyst.


30

DokumentDokument – – PflichtenheftPflichtenheft

Aktivität Pflichtenheft (Functional Specification)

Erklärung Das Pflichtenheft ist eine detaillierte Beschreibung aller Seiten der Anwendung. Element, die auf vielen Seiten vorkommen, werden nur ein Mal beschrieben.

Typischeweise enthält das Dokument schematische Seitendarstellungen, gefolgt von einer Beschreibung der Funktion aller darauf sichtbaren Elemente. Die Herkunft der sichbaren Daten wird erklärt, ebenso die Funktion von interaktiven und Kontrollelementen. Geschäftsprozesse, die für die Funktion der Seite von Bedeutung sind, werden erklärt.

Zweck Das Ziel ist ein Dokument mit einer möglichst detailerten Beschreibung der Funktionen der Anwendung. Die Anwendung wird gemäß dieser Beschreibung entwickelt


31

DokumentDokument – Schemati – Schematische Seitengrafikensche Seitengrafiken

Aktivität Schematics

Erklärung Schematische Seitengrafiken zeigen den Inhalt und das Layout einer Seite in schematischer Form, ohne auf die grafische Umsetzung Rücksicht zu nehmen. Die Navigationselement sind ebenfalls sichtbar.

Diese schematischen Grafiken werden gebraucht, um möglichst früh dem Auftraggeber eine Idee zu vermitteln, wie das Endprodukt gestaltet sein wird.

Der Information Architekt arbeitet dabei eng mit dem Solution Architekt zusammen, damit gewährleistet ist, daß die Seiten in dieser Form ohne technische Probleme implementiert werden können.

Zweck Definition der Navigationselement und Seitenelemente. Bestimmte Schwierigkeiten in der Umsetzung, die sonst erst während der Programmierung auftreten würden, können so schon frühzeitig behandelt werden.


32

Schematics . . . Schematics . . .

<company logo>

Beispiel eines SeitensBeispiel eines Seitenschemachemass


33

DokumentDokument – Design Comps – Design Comps

Aktivität Design Comps

Erklärung Vollfarbige Umsetzung von wichtigen Seiten. Nicht alle Seiten werden als Design Comps umgesetzt, der Aufwand wäre zu groß.

Zweck Vorschau auf einige wesentlich fertig gestalteten Seiten.


34

Design Comps. . . . Design Comps. . . .

Beispiel – Design CompBeispiel – Design Comp


35

Phase 4 - Technische AnalysePhase 4 - Technische Analyse

Diese Phase kann sinvollerweise erst dann beginnen, wenn alle vorhergehenden Phasen im Wesentlichen abgeschlossen sind.

Spätere Änderungen am Pflichtenheft oder anderen Voraussetzungen führen zu kostenintensivem Redesign.

Es ist deshalb wichtig, daß Pflichtenheft, Seitenschemata und Design Comps vom Kunden abgenommen sind.

Änderungen werden ab nun dokumentiert und als “Scope Change” zum Projektleiter oder Lenkungsausschuß eskaliert.

Federführend ist ab jetzt in allen Phasen der Technische Architekt.


36

Dokument - HW und SW AnforderungenDokument - HW und SW Anforderungen

Das Dokument verbindet Informationen überNetzwerktopologieServerhardware (vorhanden oder zuzukaufen)FremdsoftwareLegacy-Applikationen

zu einer detaillierten Zusammenstellung der Systemkonfiguration der Laufzeitumgebung.

Lastanalysen begründen die Dimensionierung

Die Konfiguration der Entwicklungsumgebung, einschließlich Maßnahmen zur Datensicherung und Sourcecodeverwaltung, sollte ebenfalls behandelt werden.


37

Beispiel – Hardware DiagrammBeispiel – Hardware Diagramm

SharedStorageDevice

Sun E3500

Sun E450

Web/ApplicationServer

Database Server

Firewall

Windows NT

MarketFirstServer

Internet

TBD

WebReporting

Server

Sun E250

Webserver

Sun E250

Webserver

Firewall

Sun E3500

ApplicationServer

Sun E3500

ApplicationServer

Production Environment

Staging Environment

Site Management Environment

Sun E250

Web/Application /

DatabaseServer

Sun E250

Web/Application/Database

Server

Development QAEnvironment

Mgmt Database Server

Market FirstDatabase

WebReportingDatabase

Sun E250

Phase 2

Sun E450

DatabaseServerCluster

Sun E450

SharedStorageDevice

SharedStorageDevice

Sun E250

SearchServer

FTP Server


38

Dokument – Technisches Design Dokument – Technisches Design

Das Technische Design enthältDas vollständige DatenmodellEine Beschreibung der Assets*

Eine Beschreibung der Komponenten (Module), aus denen einzelne Seiten aufgebaut sind, mit Aufrufparametern, Rückgabewerten und abhängigen DatenbanktabellenEine Beschreibung aller individueller Anpassungen von Fremdsoftware (z.B. Content Management System, Suchmaschine, Web Reporting etc.)Schnittstellen zu externen AnwendungenBeschreibung von Wartungs- und Batchprozessen

Nach dem Pflichtenheft das zweitumfangreichste Dokument


39

Phase 5 - UmsetzungPhase 5 - Umsetzung

In dieser Phase wird die Applikation entwickelt, getestet und in Produktion genommen.


40

Vielen Dank für Ihre Aufmerksamkeit!

Documents

1 17.7.2003 21:33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten. Architektur