Über die Vorlesung
In der Vorlesung „Web Engineering“ lernt man, welche besonderen Herausforderungen Web-Projekte beinhalten und wie man damit umgehen kann. Es wird zwar auch über technische Aspekte geredet (siehe Part 1), aber es geht vor allem um Projektplanung und -management. Insbesondere wird hier nichts konkret entwickelt. Dafür gibt es vermutlich das Praktikum, das aber unabhängig von der Vorlesung ist.
Herr Dr. Nussbaumer hält die Vorlesung sehr interaktiv. Er stellt viele Fragen, über die man in der Vorlesung diskutieren kann und ist auch immer nach der Vorlesung bereit etwas genauer zu erklären.
Die Struktur unter „Vorbereitung“ richtet sich nach dem Aufbau der Folien.
Vorbereitung
Prüfungsprotokolle sind bei der Fachschaft Informatik zu erhalten. Mein Prüfungsprotokoll ist hier und die TeX-Quelldateien bekommt ihr natürlich auch.
Im Folgenden sind einige Stichpunkte aufgelistet, die jedem etwas sagen sollten.
Geschichte
- 1945: Vannevar Bush, Memex
- 1965: Ted Nelson, Hypertext und Xanadu
- 1969: ARPANET
- 1985: Bill Atkinson (Apple), HyperCard
- 1989: Tim Berners-Lee, World Wide Web
- 1993: Mosaic
PART 1: Technologies
- Markup, HTML, Ressources, Cookies, MIME
- Host, Server, Client, User Agent
- Hypertext Paradigm
- HTTP, HTTPS, FTP, SMTP, UDDI
- CGI
- SOAP, WebDAV
- Moore's Law, Nielson's Law
- Was ist der Unterschied zwischen Software Engineering und Web Engineering? → Antwort auf Folie 47ff, part0-1
- Paretoprinzip
- Was ist das W3C? Was sind die Ziele des W3C? Wer ist Teil des W3C?
- Zone File
- Uniform addressing → Was ist das?
- URI, URL, URN, URC, RFC1630
PART 2: Project Management
- Chaos-Report der Standish Group (25%, 45%, 30%)
- Bad: Very high budget
- Good: Executive Management, User Involvement, Experienced Project Manager, Clear Business Objectives, Minimizing Scope, Requirements Process, Standard Software Infrastructure, Formal Methology, Reliable Estimates, Skilled Staff
- „When projects fail, it's rarely technical.“
- Outsource, Find&Buy, Develop new solution
Teams:
- < 6 Entwickler
- < 6 Monate
- RERO
- Verantwortungsbereiche:
- Product Management: Wie verkaufe ich die Software?
- Program Management: Wie bringe ich das Projekt zu einem erfolgreichem Abschluss?
- Architekture: Wie halte ich die Software erweiterbar, anpassbar und wartbar?
- Development: Wie schreibe ich den Code von Methode abc in Klasse xyz?
- Test: Sind alle funktionalen und qualitativen Anforderungen erfüllt? Ist das System robust?
- User Experience: Passiert das, was der Nutzer erwartet? Kann man dem User die Bedienung der Software erleichtern?
- Release / Operations: Wie halte ich die Software über Jahre am laufen?
- Aufsplitten der Teams nach Funktionen oder Features
- Wo ist der Unterschied?
Tasks & Tools
- Work Breakdown Structure
- GANTT chart
- PERT
- SWOT Analysis
Risiken
- Cost-reduction expectations
- Data security / protection (IPR)
- Process discipline (Was ist das?)
- Loss of business knowledge
- Vendor failure to deliver
- Scope creep
- Government oversight / regulation
- Culture (language and callcenters)
- Turnover of key personnel
- Knowledge transfer
Process Models
- Code and fix
- Waterfall model
- Prototyping model
- Evolutionary Development model: Only for small, scientific projects where project goal is unclear
- Spiral model: Risk-driven
- RUP von SAP
- MSF → msdn Artikel
- Rollen:
- Product Management: Anwalt des Kunden, teamübergreifende Projekt-Vision, betriebswirtschaftliche Sicht auf das Projekt
- Program Management: „Projektleiter“, Teamkommunikation, technische Sicht auf das Projekt
- Architecture, Development, Testing, Release / Operations
- User Experience: Anwalt des Benutzers
- Skalierung: Feature-Teams vs. Functional Teams
- Meilensteine: Extern sichtbare und Interim-Meilensteine
- Rollen:
- Reuse-Oriented Approaches
- Agile Methoden:
- Scrum:
- Rollen: Scrum Master, Product Owner, Development Team
- Iterations, Sprints, User Stories
- Scrum Plakat
- Video: What is Scrum?, Scrum in 8 minutes, Scrum Refcard, Scrum Master Checklist
- XP: Paarprogrammierung, Lecture 24: Richard Buckland (45 minutes)
- Agile manifesto
- Scrum:
PART 3: Requirements Engineering
- Ablauf:
- Initiate: Project Charter, Identify business opportunity, gather business requirements, FOR WHO THE IS THAT UNLIKE OUR PRODUCT
- Elicitation: Refine requirements (Busines requirements, functional requirements, non-functional requirements), Coopers Persona-Ansatz (Beispiele)
- Asses: Understand and organize requirements, features and feature sets
- Specification: Software requirements specification
- Validation
- Gather requirements (Interviewing, Shadowing, surveys, brainstorming, user instructions - z.B. bei Atomkraftwerken gibt es wohl schon Prozessabläufe)
- A11Y, L10N, I18N, G11N: BITV
- RNA: Relationship-Navigation Analysis
- WAI
PART 4: Entwurf
Logischer Entwurf (Abstrakt: Wireframes, Navigation patterns) ↔ Physikalischer Entwurf (Konkret: UI Frameworks, Services)
Content Management Aspects
- Content-Typen müssen definiert werden, um Inhalte von der Darstellung trennen zu können
- Content-Typen sind auch für die Suche relevant
- Templates müssen erstellt werden
- Welche Metadaten liegen vor?
- Wie können Metadaten weitergegeben werden? → Rich Snippets
- Welche Arbeitsabläufe habe ich?
- Inhalt kann in flachen/strukturierten Dateien oder in Datenbanken liegen.
- Strukturierte Dateien: XML, RDF (→ Video), Microformats
Software Interface Aspects
- User-centered design → Wiki
- Mentale Modelle: Taschenrechner, Explorer, Start-Vorgang, Einkaufssysteme, Hyperlinks, Tastatur
- Metaphern
- User-Modelle: Rollen, Markt-Anteile, Personas
Hypertext Systm Aspects
- Known-item search / exploratory search
Business Process Aspects
Kommt noch
Weiteres
- WSDL
- MSF vs. Scrum - Roles in Scrum
- HTTP
Weitere Informationen
Folgende Artikel sollte man lesen:
Diese Tutorials sollte man machen:
Typische Fragen
- It's not science, and it isn't exactly engineering, either.
- Disziplin aus Disziplinen (Software Engineering, Hypermedia, Information Systems, Network Engineering)
- Teilweise ist es wie Software Engineering (Requirements engineering, reproduzierbare Erfolge durch strukturierte Herangehensweise), teilweise hat es typische Problemquellen, die im Software Engineering weniger verbreitet sind (Skalierbarkeit, Load balancing, Hypermedia).
- Address (Wo ist der Endpoint?)
- Binding (Wie verbinde ich? Protokoll? Encoding?)
- Contract (Welche Informationen will ich übertragen?)
- Web for Everyone
- Web on Everything
- Knowledge Base
- Trust and Confidence
Interessante Fragen
- Web Services sind leichter skalierbar.
Hintergrundwissen
What really happens when you navigate to a URL
- OS-DNS-Cache on Linux
- What exactly happens when you browse a website in your browser? (fun to read)
- What happens when you type in a URL in browser? (well structured)
Termine
Web Engineering wird mündlich geprüft. Dazu muss man sich bei Herrn Matthias Keller ([email protected]) melden und einen Termin ausmachen. Zusätzlich muss man sich über QISPOS anmelden.
Datum: Dienstag, der 19. Februar 2013 um 14:30 Uhr (individuell, siehe Organisation)
Ort: Geb. 20.21 (SCC), Raum 303 (individuell, siehe Organisation)
Dauer: 15 Minuten
Punkte: 4 ECTS