DI Christian Donner cd (at) donners.com

DI Christian Donner cd (at) donners.com
Architektur Moderner Internet Applikationen TU Wien/Ausseninstitut Ein erprobtes Vorgehensmodell DI Christian Donner cd (at) donners.com :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Einleitung 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. Ein Vorgehensmodell ist streng genommen nicht notwendiger Bestandteil eines Vortrages über Internet-Anwendungsarchitekturen, erschien aber wichtig und interessant genug, um hier einigermaßen detailliert behandelt zu werden. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Zusammensetzung des Teams
Die folgenden Projektrollen sind typischerweise vertreten: Projektsponsoren oder Lenkungsausschuss Projektleiter Business Analyst, Organisator Solution Architect “Client Partner” oder Account Manager Information Architect Web Designer QA Lead Softwareentwickler Tester Configuration Manager Eine Person kann mehrere Rollen ausüben, so z.B. ist der Projektmanager bei kleineren Projekten gleichzeitig der Business Analyst oder der Architekt gleichzeitig der Configuration Manager. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben der Projektsponsoren
Typischweise Vertreter des Managements von Auftraggeber und Auftragnehmer Klassische Rollen: Bereitstellung von Budget und Resourcen Buy-In bei Endbenutzern sicherstellen Definition der Projektziele Letzte Kontrollinstanz für Projektfortschritt Vermittlung bei Krisen, die von niedrigeren Ebenen eskaliert wurden Entscheidungsinstanz bei Budget- und Terminüberschreitungen :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben des Projektleiters
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 Reale Projekte haben oft die Tendenz, sich rasch von den ursprünglichen Annahmen wegzuentwickeln. Dies ist besonders dann der Fall, wenn unerfahrene Teams am Werk sind oder unrealistische kaufmännische Randbedingungen gesetzt wurden. In solchen Projekten ändern sich Anforderungen, Prioritäten und Termine. Oft werden sogar Projektmitglieder ausgetauscht. Dabei ist wegen des entstehende Arbeitsaufwandes die Versuchung groß, den Projektplan und die Projektdokumentation nicht anzupassen. Es hat sich jedoch gezeigt, daß ein aktueller Projektplan umso wichtiger wird, je öfter es Änderungen im Projekt gibt. Daher ist es sehr empfehlenswert, für die Aktivitäten zur Wartung der Dokumentation auch entsprechend Zeit einzuplanen. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben des Solution Architect
Festlegung der Hard- und Softwareplattform Erstellung des Anwendungsdesigns Datenbankdesign Applikationsdesign Schnittstellen Leitung der Entwicklungsphase Mentor und Anlaufstelle für Softwareentwickler Arbeitszuteilung und Abnahme von Modulen Fehlermanagement (Defects) Code Reviews Produktionsstart :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben des Business Analyst
Abhaltung von Workshops zur Anforderungsanalyse Erstellung des Pflichtenhefts Training der Benutzer :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben 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 :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben 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 :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben des Webdesigners
Erstellung eines Styleguides Farben Schriftarten und –größen Bildgrößen Graphisches Layout Erstellung von “Design Comps”, graphischen Elementen und Animationen Design Comps sind vollwertige graphische Umsetzungen einzelner Webseiten. Sie dienen dem Team zur Präsentation des zukünftigen Sites bei den verantworlichen Stellen, der Abnahme des Designs und schließlich auch den Entwicklern als Vorlage. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben des QA Lead Erstellung des Testplans Durchführung von Tests
Definition des Fehlerbehebungsprozesses Konfiguration von Tools :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Aufgaben des Configuration Manager
Durchführung von Releases Zusammenfassung von Änderungen zu einer Release Physische Durchführung, evtl. Teilautomatisiert Release-Dokumentation Verantwortlich für Versionskontrolle :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

5-Stufiges Vorgehensmodell
Projekte, die die Erstellung einer Website beinhalten, betreffen meist mehrere Abteilungen oder oft sogar das ganze Unternehmen. Für den Berater stellt sich das Problem, dass ein Konsens zwischen Personen oder Teams erreicht werden muss, die wenig Erfahrung mit EDV Projekten haben und die eine gemeinsame Problemlösung nicht gewohnt sind. Deshalb ist es wichtig, die Anforderungen iterativ zu erarbeiten und früh und zahlreich Möglichkeiten für Feedback in den Projektplan einzubauen. In der Praxis hat sich ein dreistufiges Top-Down Modell bewährt. Folgende Personengruppen müssen eingebunden sein: Management aller beteiligten Organisationseinheiten (zur Definition der Ziele und Priorisierung der Inhalte) Personen, die Inhalte für die Website bereitstellen (das Management kennt häufig die eigenen Geschäftsprozesse nicht) Endbenutzer (das Management kennt häufig die Bedürfnisse und Wünsche der eigenen Kunden nicht) Team, das die Anwendung wartet und verwaltet Aus den Informationen, die von diesen Gruppen gewonnen werden, müssen folgende Dokumente erstellt werden: Die „Information Architecture Recommendations“ können direkt im Workshop erarbeitet werden und beinhalten eine Strukturierung und Priorisierung der vorhandenen Informationen für den Endbenutzer. In Textform werden die einzelnen Bereiche der Site und die Navigationsstrukturen beschrieben Eine schematische Seitenbeschreibung visualisiert diese Erkenntnisse. Darauf aufbauend gibt das Pflichtenheft sehr detailiert Aufschluß über das dynamische Verhalten der Sites. Die Funktion aller Komponenten auf allen Seiten wird darin beschrieben. Das Technische Design setzt diese Anforderungen in technische Anweisungen für die Entwickler um. Darin findet sich typischerweise ein Datenmodell, eine Beschreibung der Schnittstellen einzelner Softwaremodule und oft auch des Innenlebens dieser Module Die Hard- und Softwareanforderungen beschreiben die Infrastruktur, die für den Betrieb der Anwendung unter den gegebenen Randbedingungen erforderlich ist. Nicht berücksichtigt wurden Testplan und Implementierungsplan. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Phase 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. Aktivitäten zur Anforderungsanalyse: Präsentation der Ergebnisse des Mitbewerber-Audits und der Heuristischen Evaluierung der bestehenden Anwendung. Diese fließen in die weiteren Aktivitäten ein: Workshop: Business Goals, User Needs, User Roles Workshop: Präsentation Feature/Funktion-Analyse Workshop: Abgleich von Navigation und Inhalten Focus Groups: Eine Auswahl von Endbenutzern der Anwendung, gewöhnlich Kunden des Auftraggebers, wird identifiziert und zu Einzelinterviews eingeladen, in der sie einen sorgfältig ausgearbeiteten Fragebogen zu ihren Erwartungen und Bedürfnissen mit der Anwendung befragt werden. Das Ergebnis wird dazu verwendet, um das Verständnis auf Seite des Auftraggebers von Benutzerbedürfnissen und Benutzerrollen zu validieren. Zusammensetzung der Workshops Auftragnehmer: Projektleiter, Information Architect, BA, Architekt Auftraggeber: Vertreter aller Abteilungen, die direkt oder indirekt von der Anwendung profitieren möchten :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Workshop – Business Goals, User Roles, 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. Ein Beispiel für Rollen und Bedürfnisse: Rolle: Presse/Medien Bedürfnis: Ich brauche Informationen über die finanzielle Situation und die Marktposition einer Firma, um einen Artikel zu schreiben. Aktivitäten zur Erfüllung dieses Bedürfnisses: Suche nach Ratings und Rating-Änderungen Lese Börsenausblick und Kommentare Lese wirtschaftlichen Ausblick und Kommentare Lese relevante Artikel und Kommentare Studiere Daten und Statistiken Lese Firmenprofil Bedürfnis : Ich brauche die Telefonnummer eines Analysten für ein Interview. Suche nach der Kontaktinformation des Analysten :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Workshop – Content Lebenszyklus
Wie entstehen Inhalte, wie gelangen sie auf den Website und wann und wie verschwinden sie wieder? 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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Analyse – Features/Funktionen
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. Für diesen Schritt gibt es kein formales Dokument, das dem Auftraggeber übergeben wird. Stattdessen werden im IA Anforderungsdokument (dem formalen Ergebnis der Phase Informationsanalyse) zu jeder Seite die Funktionen gelistet, die an dieser Stelle zur Erfüllung der Benutzerbedürfnisse angeboten werden. Als Hindernis (“barrier”) definieren wir, wenn eine Testperson auf Grund schlechter Navigation, Darstellung oder Anordnung von Daten eine gestellte Aufgabe nicht oder nur mit Schwierigkeiten lösen kann. Dazu versetzt sich der Information Architekt entweder selbst in die Rolle des Benutzers, oder verwendet reale Testpersonen. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Phase 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-Audit Heuristische Evaluierung Site Plan (site map) Schematische Seitendiagramme :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – IA 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. Beispiel: Recent News & Analysis List Recommendation: Display a short list of the most recent News & Analysis articles on the Home page that link to the full article. Analysis: In order to entice users to the wealth of News & Analysis available on the site, display a short list of the most recent News & Analysis articles on the Home page. The title within the list would link to the full article and well as a link to get more articles. This is an effective way to promote the news content of the site and direct users to the primary regionally filtered content areas where the depth of content resides. Technical Implications: Low: This can be implemented in either a semi-automated fashion (with a Web Content Manager or Web Producer choosing the articles) or a fully automated process (which would be based on business rules defined during the functional specification development). :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – Heuristische Evaluierung
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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – Mitbewerber 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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Workshop – 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. Das Ergebnis wird in Outline-Format in das IA Anforderungsdokument eingearbeitet. Beispiel (Ausschnitt): Persistent Navigation (Secondary Nav.) 6. About S&P A. Index Page i. History ii. Business Unit Description iii. Awards/Recognition iv. Biographies of Key Executives v. Affiliates B. Career Information i. <Software Tool Flow with new L&F> C. Link to McGraw Hill :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – 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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – 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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Beispiel - Style Guide Style Guide. . . .
Der Style Guide enthält außerdem Angaben zu Fonts, Schriftgrößen, der Größe von Grafiken und Designelementen in Pixel, der Größe von Tabellenfeldern etc. Vieles aus diesem Dokument fließt während der Entwicklung zweckmäßigerweise in ein Cascading Stylesheet ein (CSS). :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Umsetzung – Grafische Produktion
Aktivität Grafische Produktion Erklärung Erstellung der Grafiken für die Anwendung. Zweck Softwareentwickler brauchen die Grafiken, wenn die Programmierung der Seiten beginnt. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Umsetzung – HTML Erstellung des HTML Code
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). Systeme zur Entwicklung dynamischer Web-Applikationen, Content Management Systeme und andere zu integrierende Systeme haben oft Anforderungen an das Layout und die spezifische Umsetzung von HTML Code, die einem grafischen Designer nicht bekannt sind. Code, der an solchen Anforderungen vorbeientwicklelt wurde, muß dann oft von den Softwareentwicklern neu geschrieben werden. Auch wird Code-Reuse von solcherart erstellten HTML Seiten eher behindert, weil der Softwareentwickler später den kompletten HTML Code einer Seite in wiederverwendbare Komponenten aufbrechen muß. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Phase 3 - Funktionale Analyse
Diese Phase läuft teilweise parallel mit der Analyse der Informationsarchitektur Federführend ist der Business Analyst. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – Pflichtenheft
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 Wenn das Pflichtenheft unvollständig ist, kommt es später bei der Entwicklung zu Verzögerungen, weil Entwickler beim Business Analysten nachfragen müssen. Außerdem besteht dann das Risiko, daß die nachträglich definierte Funktionalität zu Konflikten mit bestehenden Funktionen führt. Dieses Dokument ist daher der Schlüssel zu einer möglichst kurzen und problemfreien Entwicklungsphase. Es ist üblicherweise das umfangreichste Dokument, daß im Zuge eines Projektes erstellt wird, und umfaßt bei größeren Projekten 500 Seiten oder mehr. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – Schematische 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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – 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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Phase 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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument - HW und SW Anforderungen
Das Dokument verbindet Informationen über Netzwerktopologie Serverhardware (vorhanden oder zuzukaufen) Fremdsoftware Legacy-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. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Dokument – Technisches Design
Das Technische Design enthält Das vollständige Datenmodell Eine Beschreibung der Assets* Eine Beschreibung der Komponenten (Module), aus denen einzelne Seiten aufgebaut sind, mit Aufrufparametern, Rückgabewerten und abhängigen Datenbanktabellen Eine Beschreibung aller individueller Anpassungen von Fremdsoftware (z.B. Content Management System, Suchmaschine, Web Reporting etc.) Schnittstellen zu externen Anwendungen Beschreibung von Wartungs- und Batchprozessen Nach dem Pflichtenheft das zweitumfangreichste Dokument Asset ist ein produkt-spezifischer Begriff aus der Content Management-Welt. Er bezeichnet einen Typ von Inhalt, der mit dem System verwaltet wird. Ein Asset hat spezifische Attribute mit Eigenschaften, die das Verhalten auf Eingabe- und Suchformularen steuern.  <PROPERTY NAME="title" DESCRIPTION="Title"> <STORAGE TYPE="VARCHAR" LENGTH="255" /> <INPUTFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="255" REQUIRED="YES"/> <SEARCHFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="255" DESCRIPTION="Title Contains:"/> </PROPERTY>  <PROPERTY NAME="abstract" DESCRIPTION="Abstract"> <INPUTFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="255" REQUIRED="NO"/> <SEARCHFORM TYPE="TEXT" WIDTH="48" MAXLENGTH="255" DESCRIPTION="Abstract Contains:"/>  <PROPERTY NAME="urlbody" DESCRIPTION="Body"> <STORAGE TYPE="VARCHAR" LENGTH="50000" /> <INPUTFORM TYPE="TEXTAREA" ROWS="24" COLS="48" REQUIRED="NO"/> :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

Phase 5 - Umsetzung In dieser Phase wird die Applikation entwickelt, getestet und in Produktion genommen. :33 Architektur Moderner Internet Applikationen – Vorgehensmodell Copyright ©2003 Christian Donner. Alle Rechte vorbehalten.

DI Christian Donner cd (at) donners.com

Ähnliche Präsentationen

Präsentation zum Thema: "DI Christian Donner cd (at) donners.com"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

DI Christian Donner cd (at) donners.com

Ähnliche Präsentationen

Präsentation zum Thema: "DI Christian Donner cd (at) donners.com"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback