SlideShare ist ein Scribd-Unternehmen logo
1 von 56
Universität zu Köln. Historisch-Kulturwissenschaftliche Informationsverarbeitung
Dr. Jan G. Wieners // jan.wieners@uni-koeln.de
Basisinformationstechnologie I
Wintersemester 2015/16
07. Dezember 2015 – Software-Entwicklung: klassisch vs. agil
Phasen der Software-Entwicklung
 Analyse
 Spezifikation
 Entwurf
 Algorithmus
 Pseudocode
 Implementation
 (Post-Implementation)
Vorgehensmodelle
 Wasserfallmodell
 Prototypische Entwicklung
 Iterative Entwicklung
 Iterativ inkrementelle Entwicklung
Agile Software-Entwicklung
 Intention
 Werkzeuge und Methoden
 User Stories
 User Story Mapping
Themenüberblick „Software-Entwicklung: klassisch vs. agil“
Ergänzungen
„Betriebssysteme“
Speicherverwaltung: Swapping
 Problem: Externe Fragmentierung
Speicherverwaltung: Paging / Kachelverwaltung
MMU (Memory Management Unit) kümmert sich um
die Übersetzung virtueller Speicheradressen auf
den physikalischen Speicherbereich
Paging: MMU
Quelle: Tanenbaum: Moderne Betriebssysteme
Grundproblematik: Inkonsistenzen im Dateisystem
Z.B. Systemabsturz  Inkonsistenz
Journaling-Dateisysteme (ext3 / ext4): Änderungen
werden vor der Speicherung in einem reservierten
Speicherbereich („Journal“) aufgezeichnet.
Ergänzungen „Betriebssysteme“: ext3 / ext4
 SSDs und (De)fragmentierung?
Neulich in den
Sommerferien…
Analyse
„Regeln zur Leitung des
Geistes" (1628):
 Hohe Relevanz der
Analysephase
 Aufteilung in Teil- und
Unterprobleme
 Hierarchischer
Erkenntnisprozess
 Analyse der Analyse
i.e. Sicherung der Analyse
Analyse  Spezifikation  Lasten- /
Pflichtenheft
Entwurf
Systemarchitektur? Tools / Werkzeuge?
www.thecodinglove.com
Entwurf: Mockups
Entwurf: Algorithmus Eindeutige Beschreibung eines endlichen Verfahrens zur Lösung einer bestimmten Klasse von Problemen
„Algorithmus“, formal:
Eine Berechnungsvorschrift zur Lösung eines Problems heißt
genau dann Algorithmus, wenn eine zu dieser
Berechnungsvorschrift äquivalente Turingmaschine existiert, die
für jede Eingabe, die eine Lösung besitzt, stoppt.
TheSimpleMaths:
https://www.youtube.com/watch?v=QR8ffLPtomM
 Finitheit: Das Verfahren muss in einem endlichen
Text eindeutig beschreibbar sein.
 Ausführbarkeit: Jeder Schritt des Verfahrens muss
tatsächlich ausführbar sein.
 Platzkomplexität: Das Verfahren darf zu jedem
Zeitpunkt nur endlich viel Speicherplatz benötigen.
 Zeitkomplexität und Terminierung: Das Verfahren
darf nur endlich viele Schritte benötigen.
Algorithmus + Turingmaschine
Finden Sie einen Weg aus dem Labyrinth
Entwerfen Sie ein Verfahren, das Sie aus jedem Labyrinth (mit Ausgang) führt
Pledge-Algorithmus:
 Prämisse: Wir gehen davon aus, dass alle Ecken rechtwinklig
sind
 Somit kommen nur Rechtsdrehungen und Linksdrehungen um
jeweils 90 Grad vor
 Wir verwalten unterwegs einen Umdrehungszähler, der:
 bei jeder Linksdrehung um eins erhöht und
 bei jeder Rechtsdrehung um eins verringert wird (auch bei der
ersten Rechtsdrehung, die nach dem Auftreffen auf eine Wand
ausgeführt wird).
 Zu Beginn wird dieser Umdrehungszähler auf null gesetzt
 Anschließend werden die beiden Anweisungen
 geradeaus, bis Wand erreicht
 Folge der Wand, bis Umdrehungszähler = 0
solange wiederholt, bis wir ins Freie gelangen
Programmentwicklung: Entwurfsphase
Pseudocode Pledge-Algorithmus:
Setze Umdrehungszähler auf 0;
Wiederhole
 Wiederhole
 Gehe geradeaus;
 Solange Wand erreicht;
 Drehe nach rechts;
 Wiederhole
 Folge dem Hindernis;
 Solange Umdrehungszähler=0;
Solange ins Helle gelangt;
 Entwurf unabhängig von der Programmiersprache!
Implementation
Programmerstellung und Programmiersprachen
Programmiersprachen
Strukturierte Computerorganisation
Problemorientierte Sprache
Assemblersprache
Betriebssystemmaschine
Befehlssatzarchitektur (ISA)
Mikroarchitektur
Digitale Logik
Ebene 5
Ebene 4
Ebene 3
Ebene 2
Ebene 1
Ebene 0
Vorgehensmodelle
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Wasserfallmodell
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Prototypische Entwicklung
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Prototyp
Iterative Entwicklung
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Test und Integration
Iterativ Inkrementelle Entwicklung (State of the Art)
Manifest für Agile Software-Entwicklung
 2001 veröffentlicht von 17 renommierten Entwicklern
[http://agilemanifesto.org/iso/de]
Intention / Grundpfeiler:
 Individuen und Interaktionen haben Vorrang vor
Prozessen und Werkzeugen
 Funktionsfähige Produkte haben Vorrang vor
ausgedehnter Dokumentation
 Zusammenarbeit mit dem Kunden hat Vorrang vor
Vertragsverhandlungen
 Das Eingehen auf Änderungen hat Vorrang vor strikter
Planverfolgung.
 Arbeit in Sprints
 Feedback maximieren durch zeitnahe Software-
Inkremente
 Testgetriebene Entwicklung
 Refaktorisierung
 Codereviews
 Pair Programming
 User Stories / User Story Mapping
 …
Agile Entwicklung, so funktioniert‘s
"Als <Rolle> möchte ich <Ziel/Wunsch>, um
<Nutzen>"
[https://www.holisticon.de/2013/06/user-story-cards-aufs-wesentliche-reduziert/]
Product Backlog
mit priorisierten
Aufgaben
Quelle: Jeff Patton, http://agileproductdesign.com/presentations/user_story_mapping/index.html
Unter jeder Aktivität / jedem
Feature: Entsprechende User
Stories
Quelle: Jeff Patton, http://agileproductdesign.com/presentations/user_story_mapping/index.html
Ein Wanderer kommt an eine Weggabelung. Er weiß,
dass der eine Weg ins Dorf führt, der andere jedoch in
einen Sumpf - und da will er nicht hin.
An der Gabelung steht ein Haus, und in dem Haus
wohnen zwei Zwillinge, die man nicht unterscheiden
kann - sie kennen den Weg. Einer der Zwillinge lügt
immer, der andere nie.
Wenn der Wanderer anklopft, wird einer der Zwillinge an
die Tür kommen, aber welcher es ist, das weiß der
Wanderer nicht. Der Wanderer kann genau eine Frage
stellen, um den Weg herauszufinden. Welche Frage
muss er stellen?
/

Weitere ähnliche Inhalte

Ähnlich wie Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung

Ueberlegungen Projektmanagement Web Applications
Ueberlegungen Projektmanagement Web ApplicationsUeberlegungen Projektmanagement Web Applications
Ueberlegungen Projektmanagement Web ApplicationsGünther Haslbeck
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudAarno Aukia
 
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...AKJoom
 
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Renate Pinggera
 
Continuous Integration / Deployment mit Jenkins CI
Continuous Integration / Deployment mit Jenkins CI Continuous Integration / Deployment mit Jenkins CI
Continuous Integration / Deployment mit Jenkins CI Florian Bosselmann
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsAndreas Schreiber
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshopmrdoubleb
 
Templates, Code & Tools
Templates, Code & ToolsTemplates, Code & Tools
Templates, Code & ToolsUlrich Krause
 
Technologieraum übergreifende Programmierung
Technologieraum übergreifende ProgrammierungTechnologieraum übergreifende Programmierung
Technologieraum übergreifende ProgrammierungFalk Hartmann
 
Labvolution 2017 schulungspräsentation_simplifier
Labvolution 2017 schulungspräsentation_simplifierLabvolution 2017 schulungspräsentation_simplifier
Labvolution 2017 schulungspräsentation_simplifieriTiZZiMO
 
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungDevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungMarc Müller
 
Camunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM OffensiveCamunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM Offensivecamunda services GmbH
 
Software Entwicklung im Team
Software Entwicklung im TeamSoftware Entwicklung im Team
Software Entwicklung im Teambrandts
 
2022-09_RPA-RoundTable_Baukasten RPA
2022-09_RPA-RoundTable_Baukasten RPA2022-09_RPA-RoundTable_Baukasten RPA
2022-09_RPA-RoundTable_Baukasten RPAFotiosKaramitsos
 
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...DNUG e.V.
 
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareAndreas Schreiber
 
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...Andreas Wissel
 

Ähnlich wie Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung (20)

Ueberlegungen Projektmanagement Web Applications
Ueberlegungen Projektmanagement Web ApplicationsUeberlegungen Projektmanagement Web Applications
Ueberlegungen Projektmanagement Web Applications
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
 
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...
 
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
 
Continuous Integration / Deployment mit Jenkins CI
Continuous Integration / Deployment mit Jenkins CI Continuous Integration / Deployment mit Jenkins CI
Continuous Integration / Deployment mit Jenkins CI
 
Archäoinformatik II, Wintersemester 2015 / 2016 -- User stories und User Stor...
Archäoinformatik II, Wintersemester 2015 / 2016 -- User stories und User Stor...Archäoinformatik II, Wintersemester 2015 / 2016 -- User stories und User Stor...
Archäoinformatik II, Wintersemester 2015 / 2016 -- User stories und User Stor...
 
Interactive Publishing Suite
Interactive Publishing SuiteInteractive Publishing Suite
Interactive Publishing Suite
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
Templates, Code & Tools
Templates, Code & ToolsTemplates, Code & Tools
Templates, Code & Tools
 
Technologieraum übergreifende Programmierung
Technologieraum übergreifende ProgrammierungTechnologieraum übergreifende Programmierung
Technologieraum übergreifende Programmierung
 
Labvolution 2017 schulungspräsentation_simplifier
Labvolution 2017 schulungspräsentation_simplifierLabvolution 2017 schulungspräsentation_simplifier
Labvolution 2017 schulungspräsentation_simplifier
 
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungDevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
 
Camunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM OffensiveCamunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM Offensive
 
Software Entwicklung im Team
Software Entwicklung im TeamSoftware Entwicklung im Team
Software Entwicklung im Team
 
2022-09_RPA-RoundTable_Baukasten RPA
2022-09_RPA-RoundTable_Baukasten RPA2022-09_RPA-RoundTable_Baukasten RPA
2022-09_RPA-RoundTable_Baukasten RPA
 
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
 
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher SoftwareEinsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software
 
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
 
Xidra 2016 DevOps
Xidra 2016 DevOpsXidra 2016 DevOps
Xidra 2016 DevOps
 

Mehr von Institute for Digital Humanities, University of Cologne

Mehr von Institute for Digital Humanities, University of Cologne (20)

Künstliche Intelligenz und visuelle Erzählungen: Comicanalyse | 17.04.2019 | ...
Künstliche Intelligenz und visuelle Erzählungen: Comicanalyse | 17.04.2019 | ...Künstliche Intelligenz und visuelle Erzählungen: Comicanalyse | 17.04.2019 | ...
Künstliche Intelligenz und visuelle Erzählungen: Comicanalyse | 17.04.2019 | ...
 
Augmented City –Street Art, Embodiment, Cultural Heritage & AR | 03.04.2019 |...
Augmented City –Street Art, Embodiment, Cultural Heritage & AR | 03.04.2019 |...Augmented City –Street Art, Embodiment, Cultural Heritage & AR | 03.04.2019 |...
Augmented City –Street Art, Embodiment, Cultural Heritage & AR | 03.04.2019 |...
 
Künstliche Intelligenz und visuelle Erzählungen: Comicanalyse | 03.04.2019 | ...
Künstliche Intelligenz und visuelle Erzählungen: Comicanalyse | 03.04.2019 | ...Künstliche Intelligenz und visuelle Erzählungen: Comicanalyse | 03.04.2019 | ...
Künstliche Intelligenz und visuelle Erzählungen: Comicanalyse | 03.04.2019 | ...
 
Transformation mittelhochdeutscher Erfahrungswelten – vom Text zum Computerga...
Transformation mittelhochdeutscher Erfahrungswelten – vom Text zum Computerga...Transformation mittelhochdeutscher Erfahrungswelten – vom Text zum Computerga...
Transformation mittelhochdeutscher Erfahrungswelten – vom Text zum Computerga...
 
Transformation mittelhochdeutscher Erfahrungswelten – vom Text zum Computerga...
Transformation mittelhochdeutscher Erfahrungswelten – vom Text zum Computerga...Transformation mittelhochdeutscher Erfahrungswelten – vom Text zum Computerga...
Transformation mittelhochdeutscher Erfahrungswelten – vom Text zum Computerga...
 
Bit sosem 2016-wieners-sitzung-13_ki-in-games
Bit sosem 2016-wieners-sitzung-13_ki-in-gamesBit sosem 2016-wieners-sitzung-13_ki-in-games
Bit sosem 2016-wieners-sitzung-13_ki-in-games
 
Bit sosem 2016-wieners-sitzung-12_bild-iv-computer-vision
Bit sosem 2016-wieners-sitzung-12_bild-iv-computer-visionBit sosem 2016-wieners-sitzung-12_bild-iv-computer-vision
Bit sosem 2016-wieners-sitzung-12_bild-iv-computer-vision
 
Bit sosem 2016-wieners-sitzung-11_bild-iii-filter
Bit sosem 2016-wieners-sitzung-11_bild-iii-filterBit sosem 2016-wieners-sitzung-11_bild-iii-filter
Bit sosem 2016-wieners-sitzung-11_bild-iii-filter
 
Bit sosem 2016-wieners-sitzung-10_bild-ii-punktoperationen
Bit sosem 2016-wieners-sitzung-10_bild-ii-punktoperationenBit sosem 2016-wieners-sitzung-10_bild-ii-punktoperationen
Bit sosem 2016-wieners-sitzung-10_bild-ii-punktoperationen
 
Bit sosem 2016-wieners-sitzung-09_bild-i-kompression
Bit sosem 2016-wieners-sitzung-09_bild-i-kompressionBit sosem 2016-wieners-sitzung-09_bild-i-kompression
Bit sosem 2016-wieners-sitzung-09_bild-i-kompression
 
Bit sosem 2016-wieners-sitzung-08_semantic-web
Bit sosem 2016-wieners-sitzung-08_semantic-webBit sosem 2016-wieners-sitzung-08_semantic-web
Bit sosem 2016-wieners-sitzung-08_semantic-web
 
Bit sosem 2016-wieners-sitzung-07_rechnerkommunikation-ii
Bit sosem 2016-wieners-sitzung-07_rechnerkommunikation-iiBit sosem 2016-wieners-sitzung-07_rechnerkommunikation-ii
Bit sosem 2016-wieners-sitzung-07_rechnerkommunikation-ii
 
Bit sosem 2016-wieners-sitzung-06_rechnerkommunikation
Bit sosem 2016-wieners-sitzung-06_rechnerkommunikationBit sosem 2016-wieners-sitzung-06_rechnerkommunikation
Bit sosem 2016-wieners-sitzung-06_rechnerkommunikation
 
Bit sosem 2016-wieners-sitzung-05_zellulaere-automaten-conway
Bit sosem 2016-wieners-sitzung-05_zellulaere-automaten-conwayBit sosem 2016-wieners-sitzung-05_zellulaere-automaten-conway
Bit sosem 2016-wieners-sitzung-05_zellulaere-automaten-conway
 
Bit sosem 2016-wieners-sitzung-04_theoretische-informatik
Bit sosem 2016-wieners-sitzung-04_theoretische-informatikBit sosem 2016-wieners-sitzung-04_theoretische-informatik
Bit sosem 2016-wieners-sitzung-04_theoretische-informatik
 
Bit sosem 2016-wieners-sitzung-03_algorithmen
Bit sosem 2016-wieners-sitzung-03_algorithmenBit sosem 2016-wieners-sitzung-03_algorithmen
Bit sosem 2016-wieners-sitzung-03_algorithmen
 
Bit sosem 2016-wieners-sitzung-02_datenstrukturen
Bit sosem 2016-wieners-sitzung-02_datenstrukturenBit sosem 2016-wieners-sitzung-02_datenstrukturen
Bit sosem 2016-wieners-sitzung-02_datenstrukturen
 
Bit sosem 2016-wieners-sitzung-01_auffrischung
Bit sosem 2016-wieners-sitzung-01_auffrischungBit sosem 2016-wieners-sitzung-01_auffrischung
Bit sosem 2016-wieners-sitzung-01_auffrischung
 
Bit sosem 2016-wieners-sitzung-00_themenueberblick
Bit sosem 2016-wieners-sitzung-00_themenueberblickBit sosem 2016-wieners-sitzung-00_themenueberblick
Bit sosem 2016-wieners-sitzung-00_themenueberblick
 
Bit wisem 2015-wieners-sitzung-12_Zusammenfassung I
Bit wisem 2015-wieners-sitzung-12_Zusammenfassung IBit wisem 2015-wieners-sitzung-12_Zusammenfassung I
Bit wisem 2015-wieners-sitzung-12_Zusammenfassung I
 

Bit wisem 2015-wieners-sitzung-09_Software-Entwicklung

Hinweis der Redaktion

  1. Swapping Jeder Prozess wird komplett in den Speicher geladen, darf eine gewisse Zeit laufen und wird anschließend wieder auf Festplatte ausgelagert (Stichwort „Virtueller Speicher“) Prozesse im Leerlauf werden zumeist auf der Platte gespeichert, so dass sie keinen Speicher verbrauchen, wenn sie inaktiv sind Benötigte Prozess-Segmente werden von der Speicherverwaltung geholt und in den Arbeitsspeicher geladen. Ist nicht ausreichend Platz vorhanden, werden andere Segmente auf die Festplatte ausgelagert Nachteil: Da das Swapping keine festgelegten Segmentgrößen bietet, entsteht schnell eine externe Fragmentierung (Lücken zwischen den Adressräumen der Prozesse)
  2. Paging Der Adressraum eines Programms wird in Einheiten aufgebrochen, die sogenannten Seiten (Pages) Jede Seite ist ein aneinander angrenzender Bereich von Adressen Die Seiten werden dem physischen Speicherbereich zugeordnet (auch unterteilt; hier werden die einzelnen Stücke als „Seitenrahmen“ bezeichnet)  Eine Seite und der Seitenrahmen verfügen über die gleiche Größe Zuordnung von Seitenrahmen zu Seiten über Seitentabelle Läuft der Prozess, müssen nur die benötigten Speicherseiten im Hauptspeicher liegen Greift das Programm auf einen Teil des Adressraumes zu, der sich im physischen Speicher befindet, kann die Hardware die notwendige Zuordnung sehr schnell durchführen Will das Programm dagegen auf einen Teil des Adressraumes zugreifen, der nicht im physischen Speicher ist, wird das OS benachrichtigt, das fehlende Stück zu beschaffen und den fehlgeschlagenen Befehl noch einmal auszuführen
  3. Beispielfrage: Erläutern sie den Unterschied zwischen Swapping und Paging und beschreiben sie die beim Swapping auftretenden Probleme. Beispiellösung: Da auszuführende Programme größer werden können als der Hauptspeicher und der Ablauf von Programmstücken des Programms nicht vorher vom Programmierer festgelegt werden sollte, wurde das Konzept des virtuellen Speichers entwickelt. Dabei werden Programme virtuell vom Betriebsystem in einem Bereich von der Festplatte in kleinere Segmente bzw. Seiten geteilt, die groß genug sind, um auch im Arbeitsspeicher verarbeitet werden zu können. Beim Programmablauf werden nun relevanten Seiten / Segmente in den Arbeitsspeicher geladen um sie aufzuführen. Dabei ergeben sie die Unterschiede bei Swapping und Paging. Beim Paging wird, wenn eine relevante Seite aus dem virtuellen Speicher benötigt wird, die derzeitige Seite ausgelagert und auf der Festplatte unter der virtuellen Adresse gespeichert. Die geladene Seite aus dem virtuellen Speicher erhält nun ihre physische Adresse im Arbeitspeicher und füllt diesen. Bei Swapping befinden sich mehrere Programmsegmente aus dem virtuellen Speicher, die jedoch allgemein keine festgelegte Größe haben, wie die Seiten. Wenn ein Teil des Programms benötigt wird, der nicht im Arbeitsspeicher vorhanden ist, dann wird zunächst untersucht, ob im Arbeitsspeicher für dieses Segment noch genug Platz vorhanden wäre. Wenn dies nicht der Fall ist, werden Segmente, die zurzeit nicht benötigt werden aus dem Arbeitspeicher auf die Festplatte wieder ausgelagert und an diese Stelle wird das benötigte Segment geladen. Das angesprochene Problem entsteht dabei durch die variablen Größen der Segmente. Da das ausgelagerte Segment meist immer größer ist als das benötigte, bleiben Speicherlücken zurück, die ungenutzt bleiben. Es geht dadurch Arbeitsspeicher verloren, wodurch die allgemeine Effizienz (Stichwort: externe Fragmentierung) gehemmt wird.
  4. Grundproblematik: Veränderungen von Dateien erfordern Schreiboperationen an mehreren Stellen des Speichermediums. Wird der Rechner vor Abschluss aller Operationen z.B. neu gestartet, befindet sich das Dateisystem in einem inkonsistenten Zustand (es enthält Änderungen, aber noch nicht alle Änderungen) Das Journaling-Konzept wirkt dieser Problematik entgegen. Angenommen, der Benutzer will eine Datei D aus dem Verzeichnis V1 ins Verzeichnis V2 verschieben. Dann müssen zwei Schreiboperationen durchgeführt werden: Zum einen muss der alte Eintrag auf D aus dem Verzeichnis V1 entfernt werden, zum anderen muss der neue Eintrag D in das Verzeichnis V2 hinzugefügt werden. Letzteres kann es erforderlich machen, dass das Verzeichnis V2 vergrößert wird, was dann noch weitere Veränderungen nach sich ziehen würde. Alle diese Änderungen werden nun nicht an den Stellen durchgeführt, wo sie eigentlich hin gehören, sondern sie werden zuerst in einem speziellen Bereich in das Dateisystem geschrieben, dem sogenannten Journal. Dort steht dann z. B. qualitativ: Entferne Eintrag D aus Verzeichnis V1 Füge Eintrag D dem Verzeichnis V2 hinzu Diese Vorgehensweise alleine ergibt allerdings noch nicht das gewünschte Ziel der Sicherheit gegen nicht vollständig durchgeführte Operationen, da hier wieder mitten in der Operation – vielleicht zufällig genau nach „Entferne Eintrag D aus Verzeichnis V1“ aber vor „Füge Eintrag D dem Verzeichnis V2 hinzu“ das System abstürzt. Daher muss das Journal von Zeit zu Zeit abgeschlossen werden. Dabei wird verzeichnet, wie viele Änderungen bis hier durchgeführt wurden, und es wird durch eine Prüfsumme sichergestellt, dass die Daten korrekt sind. Sinnvollerweise sollte also eine Verschiebeoperation mit dem Anlegen der Datei am neuen Ort beginnen, dann alle Daten kopieren und mit der Löschung des Verzeichniseintrags und somit auch der Freigabe des Festplattenplatzes auf dem Quelldatenträger beendet werden.
  5. Fragmentierung
  6. Bei SSDs spielt eine solche Fragmentierung keine Rolle, hier kann von der ersten und letzten Zelle gleichermaßen schnell gelesen werden, es tritt keine Verzögerung auf«, ergänzt OCZ-Techniker Stamp. „Ferner sind solche Fragmentierungen beabsichtigt, um die Last zwischen den Zellen gleichmäßig aufzuteilen. Würden beispielsweise regelmäßig nur die ersten zehn Prozent der Zellen beschrieben, nutzen sich diese schneller ab. Die Fragmentierung umgeht dieses Problem.“ Defragmentierung gar schädlich, weil NAND-Flash-Speicher nur eine begrenzte Anzahl von Schreiboperationen verträgt.
  7. Dimmu Borgir = Dunkle Burgen, Dunkle Städte
  8. Analyse des gestellten Problems  ToDo: Eine Möglichkeit entwickeln, trotz Dunkelheit einen Weg aus dem Labyrinth zu finden Spezifikation: Problembeschreibung – im Gegensatz zum Algorithmus, der die Lösung des Problems angibt Beachten: Problemkomplex exakt und vollständig beschreiben Ein- und Ausgabewerte berücksichtigen (Parameter) Randbedingungen bzw. Spezialfälle berücksichtigen
  9. Programmentwicklung: Analyse Descartes (1596-1650)
  10. Problembeschreibung – im Gegensatz zum Algorithmus, der die Lösung des Problems angibt Im Zusammenhang mit Ausschreibungen gilt das Lastenheft als Anforderungsspezifikation des Auftraggebers, worauf die möglichen Auftragnehmer mit Pflichtenheften als Umsetzungsspezifikation antworten.
  11. Spezifikation: Problembeschreibung – im Gegensatz zum Algorithmus, der die Lösung des Problems angibt
  12. Kent Beck (Extreme Programming): System wird unrentabel Terminverzögerungen Projektabbruch Hohe Fehlerrate Falsche Funktionsfülle
  13. „Programmieren im Großen“
  14. Der aus dem Englischen stammende Begriff Mock-up oder Mockup (auch Maquette) bezeichnet im Deutschen beispielsweise eine Attrappe. Er wird heute aber meist für ein maßstäblich gefertigtes Modell bzw. eine Nachbildung zu Präsentationzwecken benutzt Anders als ein „Mock-up“ ‒ ein visueller Prototyp ‒ wird der Begriff Wireframe (Drahtmodell) dazu benutzt, einen sehr frühen konzeptionellen Entwurf einer Website oder eines Software-Frontends darzustellen. Dabei spielt die Gestaltung und Funktion noch keine Rolle. Das Augenmerk liegt auf der Anordnung von Elementen und der Benutzerführung (UX, Benutzererfahrung). Es gibt zwei Arten eines Wireframes: Zum einen statische Wireframes: Dies ist eine schematische Darstellung einer einzelnen Seitenvorlage. Hier werden die grundlegenden Elemente der Seite festgehalten. Ein konzeptionelles Layout sollte erkennbar sein. Ein vollendetes Design ist nicht notwendig. Des Weiteren gibt es auch dynamische Wireframes. Diese bestehen aus mehreren Seiten, die als funktioneller Prototyp interaktiv miteinander verknüpft sind. So ist eine Navigation von einer zur anderen Seite möglich. Dynamische Wireframes werden häufig durch einen beiliegenden Navigationsbaum oder ein Flussdiagramm ergänzt, welche beide die Struktur abstrahieren und leichter verständlich machen.
  15. Terminierung von Algorithmen Wir verlangen (zumeist) von Algorithmen, dass sie terminieren, d.h. dass sie in endlicher Zeit (und möglichst schnell  Performance) ihre Arbeit erledigt haben Performanz: Geschwindigkeit der Problemlösung
  16. Grundfrage Algorithmus: Existiert ein Algorithmus, der für jedes denkbare Labyrinth, aus dem es einen Ausgang gibt, einen Weg ins Freie findet?
  17. Programmiersprache: Eine zum Formulieren von Programmen geschaffene künstliche / formale Sprache Warum braucht man so etwas? Darum:
  18. Merkmale: - potenzielle Probleme frühzeitig identifiziert, - Lösungsmöglichkeiten im Prototypen gefunden, daraus Vorgaben abgeleitet Vorteile: - frühzeitige Risikominimierung - schnelles erstes Projektergebnis Nachteile: - Anforderungen müssen fast 100%-tig sein - Prototyp (illegal) in die Entwicklung übernommen - Kunde erwartet schnell Endergebnis Optimierung: es ist möglich, in die vorherige Phase zu springen
  19. Merkmale: - Erweiterung der Prototypidee; SW wird in Iterationen entwickelt - In jeder Iteration wird System weiter verfeinert - In ersten Iterationen Schwerpunkt auf Analyse und Machbarkeit; später auf Realisierung große Vorteile: - dynamische Reaktion auf Risiken - Teilergebnisse mit Kunden diskutierbar Nachteile im Detail: - schwierige Projektplanung - schwierige Vertragssituation - Kunde erwartet zu schnell Endergebnis - Kunde sieht Anforderungen als beliebig änderbar
  20. Merkmale: - Erweiterung der Prototypidee; SW wird in Iterationen entwickelt - In jeder Iteration wird System weiter verfeinert - In ersten Iterationen Schwerpunkt auf Analyse und Machbarkeit; später auf Realisierung große Vorteile: - dynamische Reaktion auf Risiken - Teilergebnisse mit Kunden diskutierbar Nachteile im Detail: - schwierige Projektplanung - schwierige Vertragssituation - Kunde erwartet zu schnell Endergebnis - Kunde sieht Anforderungen als beliebig änderbar
  21. Utah, Skiurlaub
  22. In Alltagssprache formuliert Kurz und knapp Intention: Anforderungen an ein zu entwickelndes Software-System frühestmöglich annähern und schrittweise bestimmen Als Mitarbeiter des CoDArchLab möchte ich eine Kaffeemaschine anschaffen, um Dienstags nicht immer so müde zu sein.
  23. In Alltagssprache formuliert Kurz und knapp Intention: Anforderungen an ein zu entwickelndes Software-System frühestmöglich annähern und schrittweise bestimmen
  24. Eine Sammlung von User Stories für ein Softwareprodukt wird als product backlog bezeichnet
  25. Man fragt den einen, was der andere sagen würde, und nimmt dann das genaue Gegenteil.