140 likes | 232 Views
PRAKTISCHE ANWENDUNG DES REQUIREMENTS ENGINEERING Webarchivierung. Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen, WS 2010/11 Dozent: Prof. Dr. Manfred Thaller Referentin: Natalie Weiß
E N D
PRAKTISCHE ANWENDUNG DESREQUIREMENTS ENGINEERINGWebarchivierung Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen, WS 2010/11 Dozent: Prof. Dr. Manfred Thaller Referentin: Natalie Weiß Gruppenmitglieder: Dominik Wißkirchen, Anne Mühlbauer, Christian Faß, Timo Coutura, Stefan Kanther
Auftraggeber und Lieferant - verschmelzen in unserem Projekt - werden durch zwei Arbeitsphasen ersetzt: • 1.) Phase des Auftraggebers (Gruppe) • Konzeptionieren von realistischen Zielen, Anforderungen und Entwurf einer zeitlichen Planung • 2.) Phase des Lieferanten, Entwicklungsphase (Gruppe • wird in Untergruppen zerlegt) • Der zuvor erstellte Plan wird umgesetzt, durch die Aufteilung wird eine genaue Einteilung von Aufgabenbereichen garantiert (Ende: Semesterende)
Deadlines & Budget Diese zwei Faktoren hängen stark voneinander ab, das Bugdet gibt den Arbeitszeitraum durch die Finanzierbarkeit vor. In unserem Projekt werden die Deadlines nicht durch Budget- sondern lediglich durch Zeitfragen bestimmt. Wieviel Zeit kann jedes Gruppenmitglied realistischerweise investieren? Unsere Deadline ist das Ende des Semesters (31.03.2011)
Anforderungen an die Forschungsumgebung Soll bestehende Archive bereichern und auf diese aufbauen. Komponenten: • - Untersuchen/Vergleichen des Codes und dessen Aufteilung (unter anderem durch Diagramme) • - Virtuelle Darstellung der Seiten • - Historie, signifikante Veränderungen (bei Wayback durch Sternchen vermerkt, bei uns durch konkrete Informationen, was wurde verändert?) • - Kommentarfunktion
Fokus auf Realisierbarkeit Zu hohe, falsche und sich ändernde Anforderungen? Bei dem Entwurf unserer Forschungsumgebung für das Web ist aufgefallen: • - Wir können keine Daten von Wayback beziehen und die Historie ist somit nicht realisierbar bzw. zu aufwändig (nur mit Beginn in der Gegenwart und dafür ist der Zeitraum zu gering) • - Wir müssen die Datenmengen reduzieren und haben uns für unser Projekt vorgenommen, den Fokus auf Uni-Webseiten zu legen (erstmal 10-20)
Veränderte, realistische Anforderungen an die Forschungsumgebung • - Darstellung der Seite und des Codes • - Statistiken und Daten über den Code • - Kommentarfunktion (nur mit Anmeldung nutzbar) • - (Codes verschiedener Seiten können verglichen werden, Diagramme und Statistiken -> wie bei Alexa)
Ziele, Aufbaumöglichkeiten Eine Forschungsumgebung zu entwickeln, • - die auf einen direkten Blick mehrere Informationen bereitstellt, die sonst nur roh einsehbar und nicht ausgewertet vorhanden sind • - die (auf lange Hinsicht, mit Weiterentwicklung und mit einem größeren Archiv) Trends und Prognosen über die Code-Nutzung machen kann
Welche Services gibt es bereits? • http://www.seitenreport.de/ • http://www.seitwert.de/ • http://www.cynthiasays.com/fulloptions.asp?EMSG=%0D%0A%3Cbr%3EYou+must+enter+a+URL+to+check
UMSETZUNG Entwicklungsphase
1. Phase: Informationsbeschaffung • - Auswahl von 10-20 Universitätswebsites • - Backendprogrammier entwickeln Crawler Deadline: Ende des Kalenderjahres
2. Phase: Auswertung des Codes • - (X)HTML-Doctype- Codingtechnik des Layouts (Divs, Iframes, Layouttabellen, Framesets)? • - Trennung von Inhalt und Layout: HTML zur Formatierung (font-Tag usw.) Inline-CSS oder externes Stylesheet?- Nutzung von JavaScript? Frameworks (jQuery etc.)?- XML-Version vorhanden? • - semantische Aufbereitung?- RSS? Einbindung von Twitter, Flickr, Facebook etc.? • - CMS-basiert?- Ladezeiten? Deadline: Beginn der Semesterferien
3. Phase: Layout/Frontend entwickeln • - überschaubares Design, nur die wichtigsten Informationen • - alle Fenster sind größentechnisch veränderbar • - für das Vergleichen zweier Seiten wird der Screen gesplittet Deadline: Projektende = Semesterende
Aufgaben und Tester Mitarbeit auch außerhalb des Zuständigkeitsbereiches: • - Die Gruppenmitglieder sollen in jeder Phase als "neutrale Tester" zu der Optimierung des jeweiligen Bereiches beitragen. • - Alle Gruppenmitglieder sollen idealerweise in allen Phasen von dem Projektmanager über den Stand der Dinge informiert sein und gegebenenfalls bei Schwierigkeiten behilflich sein.