2-semestrig SE-I : Einführung, allgemeine Aspekte, punktuelle Vertiefung SE-II: Vertiefung, CASE mit Werkzeugeinsatz und Projekten je nach Dozent
|
|
- Valentin Hase
- vor 8 Jahren
- Abrufe
Transkript
1
2 Software Engineering I über die Veranstaltung 2-semestrig SE-I : Einführung, allgemeine Aspekte, punktuelle Vertiefung SE-II: Vertiefung, CASE mit Werkzeugeinsatz und Projekten je nach Dozent Vorlesung / Übung 4 SWS (+ 2x Übungsgruppe je 2 SWS) Übungsmodi: Vortrag (Ergänzung der Vorlesung) Übung im Plenum (alle) Übung in den Gruppen Projektaufgabe(n) in Projektgruppen Übungsaufgaben Leistungsnachweis durch Klausur (90 min) Teilnahmeberechtigung erwerben durch Praktikum nur im WS!! keine Klausurteilnahme für Teilnehmer ohne Berechtigung zum Hauptstudium!! kein LNW für Praktikum im SS möglich!! im SS nur echte Wiederholung oder Erstablegung für HS-Berechtigte des verg. WS 2
3 Übersicht 1. Was ist Software-Engineering? Einordnung innerhalb der Informatik Teildisziplinen Grobmodell(e) 2. Lebenszyklus-Modell 3. Prozess-Modelle 4. Software-Projekte und ihr Management 5. Elemente des Software-Entwicklungsprozesses 1. Anforderungsanalyse / Requirements Engineering / Requirements Specification 2. System-Entwurf 3. Prototyp-Entwicklung und Simulation 4. Programmentwurf 5. Programmtest 6. Systemtest und Integration 7. Auslieferung 8. Wartung 9. Auswertung und Verbesserung 3
4 1. Was ist Software-Engineering? Die Software-Krise ? Karikatur der Software-Produkte (aus den 70ern): nach Erhebungen der IBM: ein Produkt verlangter Funktionsumfang 100% : 15% der Funktionen nicht geliefert 30% der Funktionen nie gebraucht, aber implementiert 15% fehlerhaft übergeben so nicht gemeint 10% nicht verlangt / bestellt, aber enthalten 30% wirklich dauerhaft eingesetzt was ist passiert? - Abgleich Funktionalität / Anforderungen bzw. Vereinbarungen - Abgleich Funktionalität / Einsatzumgebung / Gesamtbetrieblicher Prozess (Workflow) - Programmtest / Integrationstest - Abgleich Funktionalität / Anforderungen Blickwinkel auf die "Informatik" im Unternehmen Werkzeug, Hilfsmittel Automatisierung, Rationalisierung (Mark und Pfennig) Wenig Sinn für Qualitätsgedanken, Strategische Komponente eines Unternehmens im Sinne dessen Zielsetzung 4
5 Was ist Software-Engineering? Einflüsse auf das Software-Engineering Technik Rechnersysteme Projektorganisation Prozesse Programmiersprachen Techniken Methoden menschlich allzu Menschliches Methoden der Teamarbeit Personalführung "human ressource management" SE Prozess betriebl. Organisationen Ziele des Betriebs Arbeitsabläufe u. Ergebnis Qualitätsansprüche Wiederverwendbarkeit Sicherheit, Robustheit Änderungsfreundlichkeit Auftraggeber Entscheidungskriterien Klarheit der Vorstellungen Leistung soft factors (sekundäre Ziele) 5
6 Was ist Software-Engineering? Arbeitsdefinition Software-Engineering ist das geplante, systematische Vorgehen bei der Herstellung von Software unter Anwendung von Methoden und Werkzeugen der Informatik, der Betriebswirtschaft und des Personalwesens mit dem Ziel, qualitativ hochwertige Software wirtschaftlich zu produzieren. (häufiges Synonym: "ingenieurmäßige" Software-Entwicklung [z.b. Siemens]) 6
7 Was ist Software-Engineering? Problemlösen zu lösendes Problem oft unabhängig von Computer / Software Verstehen der Natur des Problems (des informatischen Kerns) kein Überstülpen von Informatik über das/jedes Problem erst Problemlösen wenn nötig, Technologie als Werkzeug für Implementation der Lösung nutzen 7
8 Umgang mit Komplexität Umgang mit Komplexität Analyse Komplexitätsreduktion Synthese Problem Zerlegung in Teilprobleme P1 P2 P3 P4 Lösung L1 L2 L3 Synthese L4 L1 L2 L3 L4 8
9 Einordnung innerhalb der Informatik Teilgebiet der praktischen Informatik: die Methodenlehre objektorientierte SW-Entwicklung mit UML Entity-Relationship-Modellierung zum Design von Informationssystemen Strukturierte Programmierung Objektorientierte Analyse und Design Jackson Structured Design (JSD). Teilgebiet der angewandten Informatik: die Pragmatik der Anwendung von Informatik- und anderen Methoden zur Herstellung von Software- Produkten bzw. zur Lösung konkreter Probleme Planung der Prozessinteraktionen in einem Echtzeitsystem mit Petri-Netzen Konzeptioneller Entwurf eines Informationssystems Regelbasierte Beschreibung eines Diagnosesystems Anwendung des Konzepts des "Chief Progammer Teams" für die Kooperationsstruktur im SW-Projekt Zustandsgraph-Beschreibung für Dialogsystem Hier: Prozessorientierte Sicht (2. Punkt) 9
10 Standpunkt in der Lehrveranstaltung ~ Leitfragen entsprechend dem pragmatischen Standpunkt Problem ABC Welche Methoden gibt es für den Problembereich ABC? Wie "funktionieren" sie? Wie kann ich das Problem darin ausdrücken? Welche Grenzen haben die Methoden? Wie verwende ich die Ergebnisse? Wie kann ich die Methoden und ihre Ergebnisse bewerten?. Software-Engineering ist das Vorgehen zur Lösung von Problemen, die Rechner- und Softwareeinsatz erfordern. 10
11 Teildisziplinen Methoden zur Gewinnung und Beschreibung von Anforderungen (Requirements) Systemanalyse, Anforderungsanalyse Modellierung Definition Entwurf (Design) Grob-, Feinentwurf Dekomposition, Modularität System-Architektur Auswertung, Bewertung, Validierung Programmentwicklung Programmier-"Paradigma" und Folgen Programmtest Fehlermodelle Modultest, Einzeltest, Integrationstest Systemtest Funktionstest, Leistungsbewertung, Sicherheitstests 11
12 Teildisziplinen - 2 Abnahmetest Übergabe Einführung (i.d. Betrieb) Schulung, Einarbeitung Dokumentation Wartung und Pflege Versions-Management Change-Management 12
13 2. Lebenszyklus-Modell der Softwarelebenszyklus ist ein Grobmodell für den Prozess der Herstellung und Anwendung von Software über die gesamte Lebensdauer, beginnend bei der Idee, endend mit der Ausmusterung bzw. der Idee für die Ablösung. Phasen: 1. Idee, Planung 2. Systemanalyse 3. Entwurf 4. Implementierung 5. Tests 6. Auslieferung / Einführung 7. Wartung / Pflege 8. Auswertung 9. Redesign Prozess (Merkmale): Aktivitäten, Ressoursen, Randbedingungen, Abläufe, Verfahren Ablaufpläne Prozessphasen: selbst wiederum Prozesse 13
14 SW - Lebenszyklus Auswertung Idee, Planung Redesign Systemanalyse Wartung / Pflege Entwurf Auslieferung / Einführung Implementierung Ideal Tests 14
15 SW - Lebenszyklus Auswertung Idee, Planung Redesign Systemanalyse Wartung / Pflege Entwurf Auslieferung / Einführung Implementierung Realität Tests 15
16 3. Software-Prozess Prozess-Modelle (= Vorgehensmodelle) welche Aktionen im SW-Lebenszyklus identifiziert / auszuführen? zu welcher Zeit? mit welchem Ergebnis? Phasenmodelle: Wasserfallmodell V-Modell Prototypingmodell Evolutionäres Modell (iteratives) Spiralmodell Transformationsmodell >> Phasen des SW-Lebenszyklus in einem modellspezifischen prozessualen Zusammenhang << 16
17 Wasserfallmodell (US DoD, Royce 1970) Voruntersuchung Anforderungsanalyse Systementwurf nächste Aktion Programmentwurf Realisierung Einzel- u. Integrationstest Systemtest Rückschritt Abnahmetest Wartung, Pflege 17
18 Wasserfallmodell Welcher Fehler verursacht größere Kosten : ein Konzeptfehler, der in Programmentwurfsphase gefunden wird oder einer, der im Systemtest gefunden wird? Warum? Sagt das Wasserfallmodell etwas über die Tätigkeiten aus, die bei Änderungswünschen auf den verschiedenen Stufen auszuführen sind? Was ist zu tun, wenn in der Testphase EINZELTEST erkannt wird, dass die Software eine geforderte Funktion / Bedingung nicht erfüllt? Vorteile: klare einfache Struktur, feste Ergebnisse einer Phase, linearisierter Lebenszyklus Nachteile: beschreibt nur die Artefakte, die am Ende einer Phase zu erzeugen sind, als Schnittstelle zur nächsten Phase keine Hinweise auf die Behandlung von Änderungen des Produkts oder der Aktivitäten während der Entwicklung abgestimmt auf Produktion mit Wiederholungsfaktor, nicht auf Prototypentwicklung " software is a creation process, not a manufactoring process. " 18
19 Wasserfallmodell mit Prototypentwicklung Voruntersuchung nächste Aktion Anforderungsanalyse Überprüfung Systementwurf Programmentwurf Verifikation Realisierung Prototyp Entwicklung Einzel- u. Integrationstest Systemtest Abnahmetest Wartung, Pflege Rückschritt 19
20 Wasserfall mit Prototyping Welche Vorteile bietet die Entwicklung eines Prototypen? 20
21 Wasserfall mit Prototypentwicklung Ausführen / Untersuchen des Prototyps : Kommunikation zwischen Entwickler und Auftraggeber ermöglichen Anforderungen überprüfen ist gewünscht? Umgang, Hantierung, Oberfläche überprüfen weitere Klärung zwischen Vertragspartnern Erkenntnisgewinn 21
22 V Modell (BM M f. Verteidigung 1992) Voruntersuchung Anforderungsanalyse überprüfe Anforderungen Abnahmetest Wartung, Pflege verifiziere Entwurf Systementwurf Programmentwurf verifiziere Entwurf Systemtest Einzel- u. Integrationstest Realisierung 22
23 V - Modell Welche Beziehungen bestehen zwischen den V-Schenkeln? Wie sind die Beziehungen zu interpretieren? Welche Tätigkeiten macht dieses Modell explizit? 23
24 V - Modell Beziehungen zwischen einander entsprechenden Anforderungen und Realisierungen bzw. Entwurfs- und Realisierungsebenen Interpretation im Sinn eines Feedback zur Überprüfung gewollte Rückwärtsschritte zur Validierung / Verifikation nicht im Wasserfallmodell enthalten bzw. als Aktionen vorgesehen 24
25 Prototyping Modell Revisionsliste Revisionsliste.... ünberprüfe Prototyp Benutzer- / Kunden- Review System- Anforde -rungen Prototyp Anforderungen Prototyp Entwurf Prototyp System Test ausgeliefertes System Fortlaufender Prototyping-Prozess zur Klärung der Aufgaben, kontinuierllichen Entwicklung des Systems, Reduktion von Risiken und Unsicherheiten 25
26 Prototyping Modell Prototyp ist Gegenstand der Kommunikation zw. Entwickler und Auftraggeber früher Test der Machbarkeit, der Akzeptanz, der Integration Prototyp mutiert über Revisionsphasen zum Produkt penible Revisionsarbeit nötig Revisions- und Versionsverwaltung regelmäßige / ständige Kommunikation nötig 26
27 Spiral Modell, evolutionäres Modell (Böhm 1988) Ziele, Alternativen, Randbedingungen Alternativen und Risiken auswerten Prototypen i Planen concept of operation validated requiorements Entwickeln und Testen validated design acceptance test 27
28 Spiral Modell / evolutionäres Modell (Böhm 1988) welche Zyklen / Iterationen sind zu identifizieren? in welcher Phase entstehen welche Dokumente / Ergebnisse? 28
29 Transformationsmodell (Balzer 1981) Revision / Vgl. mit Requirements Abfolge, Entscheidungen Transformation i Transformation Transformation Transformation System- Anforde -rungen Formale Spezifikation Test ausgeliefertes System Transformationen z.b.: Datendarstellungen, Algorithmenwahl, Optimierung, Compilation in Zielsprachen, Compilation in Zielmaschinenspr. 29
30 Transformationsmodell Einsatz einer formalen Spezifikationssprache (halb-) automatische Überführung in Realisierungsstufen abhängig von formalen Methoden Kunstaspekt der Software-Entwicklung / Programmierkunst soweit wie möglich ausgeklammert Kreativität beschränkt auf die Erfassung der Anforderungen 30
31 Wünschenswerte Eigenschaften von Prozessmodellen ein gutes Prozessmodell 1. ermöglicht Verständnis und Kommunikation gleichermaßen durch Auftraggeber und Entwickler, Nutzer, Ausführende des Prozesses 2. unterstützt die Verbesserung des Prozesses bei Wiederholung ganz oder in Teilen, den Erkenntnisgewinn über den Prozess 3. unterstützt Abwicklung und Verwaltung des Prozesses: Planung Abschätzung, Überwachung (Monitoring), Auswertung 4. ermöglicht die Unterstützung des Prozesses durch Werkzeuge auf den versch. Ebenen 5. kann in Teilen automatisiert werden 31
32 Fragen Vor und Nachteile der einzelnen Prozessmodelle Wie geht man in den einzelnen Prozessmodellen mit signifikanten Änderungen der Anforderungen in einer späten Entwicklungsphase um? Welches Modell erscheint Ihnen in dieser Hinsicht als das beste? Welche Charakteristiken der Prozessmodelle sind wesentlich für den Einsatz in einer Umgebung mit unklarem Problem- und Lösungswissen? 32
33 Software-Projekte und ihr Management Projekt Vorhaben mit folgenden Eigenschaften: zeitlich abgegrenzt (Terminvorgabe) auf ein vorgegebenes Ziel gerichtet (Zielvorgabe) mit Budget ausgestattet, komplex, innovativ neuartiges / einmaliges Problem, organisatorische Querschnittsaufgabe Bewältigung im Rahmen der Normalorganisation nicht vorgesehen oder nicht effektiv und effizient möglich -> Sonderaufgabe intensive Kooperation verschieden qualifizierter Fachleute aus unterschiedlichen Bereichen -> Teamarbeit, interdisziplinär 33
34 Software-Projekte und ihr Management - 2 Software-Entwicklung -> 2 Seiten: Vorgehensmodell <- WIE Projekt <- WER, WAS, WANN, zu welchen KOSTEN Analyse Entwurf Realisierung Projektmanagement Abgrenzung: Systementwicklung Projektmanagement Einführung 34
35 Software-Projekte und ihr Management - 3 Projektmanagement: 3 Aufgaben des Projektleiters Planung Überwachung Steuerung Ausführung: Projektteam Projektmitarbeiter Kompetenzfeld Team-Typ Projektleiter Projektteam (nicht hierarchiefrei) 35
36 Software-Projekte und ihr Management - 4 Projektplanung termingerechter Teilaufgaben wirtschaftlicher Mitteleinsatz Abschluss Grundplanung Planungsauftrag formulieren Ziele u. grundsätzliche Lösungsmöglichkeiten erarbeiten Aufwandsschätzung: (schwierig) Zeit, Mitarbeiter, Sachmittel, Kosten Terminvorschläge Entscheidungsreife 36
37 Software-Projekte und ihr Management - 4 Ausführungsplanung (Detailprojektierung) Projektorganisation Koordination durch Stabstelle (Projektkoordinator, keine Linienkompetenz) Task-Force-Organisation (volle Autorität; Parallellinie; Projektleiter) Matrix-Organisation (Dimensionen; Kompetenzkreuzung; Koordinationsfähigkeit) Probleme: Schnittstelle Projekt-/Normalorganisation Beteiligung der betroffenen Vernetzung arbeitsteilig ausgeführter Projekt-Anteile Projektstruktur Zerlegung in Teilaufgaben oder Teilprojekte Sachbezogen (technisch, zeitlich) Funktionsbezogen (organisatorisch, nach Verantwortlichkeiten Organigramm) Projektablauf / Steuerung Einzelaktivitäten, Teilaufgaben und ihre zeitliche Beziehung (Netzpläne, Stufen-, Balkendiagramme) 37
38 Software-Projekte und ihr Management - 5 Teamarbeit im Projekt Team: überschaubare Gruppe (typisch 7 Personen) gemeinsames (Arbeits-) Ziel beschränkte Mittel (Zeit, Geld) Vorteile der Teamarbeit - Synergie Team weiß mehr Team regt an Team gleicht aus Relevante Gebiete: Kommunikation Transaktionale Analyse Organisationsentwicklung psychologisches Konfliktmanagement Themenzentrierte Interaktion reiches Weiterbildungsfeld für Informatiker 38
39 Software-Projekte und ihr Management - 6 Zusammenstellung von Teams abhängig von Charakter des Projektes kreativ innovativ technologielastig, fachlich orientiert wirtschaftlich orientiert Persönlichkeitsspektren z.b. Team-Typ-Test nach Meyers-Briggs davon abgeleitet Rollen im Team Ziele: Ergänzung, Ausgleich, verbreitertes Spektrum "Casting"-Situation, Assessment-Center 39
40 Software-Projekte und ihr Management - 7 Phasen der Team-Entwicklung die Team- Entwicklungs-Uhr Orientierung: höflich, unpersönlich gespannt, vorsichtig Nahkampf unterschwellige Konflikte, Konfrontation der Personen Koalitionen, Cliquenbildung kaum Fortschritt Organisierung Entwicklg. neuer Umgangsformen, Verhaltensweisen, Feedback, Konfrontation der Standpunkte Verschmelzung ideenreich, flexibel, offen leistungsfähig, solidarisch Abschied Ausklang, Resumee Trauerarbeit Reflexion des Projekts Abschluss Abschied Reflexion Verschmelzung Effizienz Organisierung Orientierung Gährung / Klärung Nahkampf 40
41 Software-Projekte und ihr Management - 8 Arbeitsgruppe <-> Team Zusammensetzung Führung Organisation Gruppe feste Anzahl gleicher FB vgl.bare Kenntnisse feste Aufgaben kaum Wissenstransfer Gruppenleiter Sternorganisation Entscheidung durch GL beständig, nach festen Regeln organisiert indiv. Aufgabenzuordnung (Arbeitsabschnitte) Team feste Anzahl versch. FB Ergänzung der Fähigkeiten Hauptaufgabe, Lastausgleich Transfer Teamleiter meist verteilte Führung gleiche Stimme bei Entscheidungen variabel, selbstorganisiert gemeinsames Ziel neben Linienorganisation umfassende Aufgabenpakete 41
42 Verfolgen des Projektfortschritts Projektmanagement typische Fragen an das Software-Engineering-Personal: Verstehen Sie mein Problem und meine Anforderungen? Können Sie ein System entwerfen, das mein Problem und meine Anforderungen erfüllt? Wie lange wird es dauern, ein solches System zu entwickeln? Wie viel wird es kosten, Sie ein solches System entwickeln zu lassen? Projekt-Ablaufplan (Schedule) Aktivitäten, Meilensteine, Abhängigkeiten, Reihenfolgen Aufwände (Personen-Tage/Wochen/Monate, Sachaufwände) (Ab-) Lieferungen Aussagen über Termine kritischer Pfad Kapazitäten, Auslastung 42
43 Projektmanagement Projekt-Ablaufplan (Schedule) erstellen Aktivitäten, Meilensteine, Abhängigkeiten, Reihenfolgen ermitteln Aufwände (Personen- Tage/Wochen/Monate, Sachaufwände) ermitteln (Ab-) Lieferungen klären Phase Projekt Projektgliederung Phasen, Schritte, Aktivitäten identifizieren Schritt Zuordnung von Zeitdauern für die Aktivitäten Meilensteine und Ereignisse Beginn und Ende von Aktivitäten Projekt Phase 1 Phase 2 Phase 3 Schritt 1 Schritt 2 Schritt1 Schritt2 Schritt3 Schritt1 Schritt Aktivität 43
44 Aufwandschätzung Projektmanagement Zuordnung Zeitdauern zu Aktivitäten => Aufwandschätzung Meilensteine und Ereignisse Beginn und Ende von Aktivitäten Function-Point-Methode (A. J. Albrecht 79) 5 Kategorien der Produktanforderungen: Eingabedaten Abfragen Ausgaben Datenbestände Referenzdaten Klassifikation einfach, mittel, komplex Berechnungsformular Bewertung von Einflussfaktoren Berechnung der Function Points Eingabedaten Abfragen Fkt. Ausgaben Datenbestände Referenzdaten 44
45 Aufwandschätzung: Function Point Methode Projektmanagement Kategorie Anzahl Klasifizierung Gewichtung Zeilensumme Eingabedaten einfach x 3 = mittel x 4 = komplex x 6 = Abfragen einfach x 3 = mittel x 4 = komplex x 6 = Ausgaben einfach x 4 = mittel x 5 = komplex x 7 = Datenbestände einfach x 7 = mittel x 10 = komplex x 15 = Referenzdaten einfach x 5 = mittel x 7 = komplex x 10 = Summe E1 = 45
46 Aufwandschätzung Function-Point Point-Methode Projektmanagement Einflussfaktoren 1 Verflechtung mit anderen Systemen (0-5) = a b c d Summe 1-7 Dezentrale Daten, dezentrale Verarbeitung (0-5) Transaktionsrate (0-5) Verarbeitungslogik Rechenoperationen (0-10) Kontrollverfahren (0-5) Ausnahmeregelungen (0-10) Logik (0-5) Wiederverwendbarkeit (0-5) Datenkonvertierungen (0-5) Anpassbarkeit (0-5) E2 = = = = = = = = = = Einflussbewertung E2 / E3 = Function Points E1 * E3 = 46
47 Aufwandschätzung Function-Point Point-Methode Projektmanagement 6. Schritt: Ablesen des Aufwands in MM aus Wertepaar-Tabelle (Function Points / MM) Voraussetzung: ausreichende Anzahl ausgewerteter / bewerteter Projekte Beispiel (IBM-Quelle): Function-P IBM MM
48 Netzplantechnik: Beispiel CPM-Methode Methode Projektmanagement CPM: critical path method Voraussetzungen: Projektgliederung Projekt auf Einzelaktivitäten / Vorgänge gebrochen Einzelaktivitäten / Vorgänge Aufwandschätzung durchgeführt Meilensteine / Ablieferungen definiert Netzwerkdarstellung Vorgangspfeilnetze / Netzpläne
49 Netzplantechnik: CPM-Methode Methode Projektmanagement Elemente: Vorgang <Vorgangsbezeichner> mit Anfangsereignis i und Endeereignis j i <Vorgangsbezeichner> (i-j) j Grundregeln: A 1 (1-2) 2 Jeder Vorgang beginnt und endet mit einem Ereignis. j ist Nachfolgeereignis von i. 1 A 2 B 3 C 4 A und B müssen beendet sein bevor C beginnen kann 49
50 Netzplantechnik: Beispiel CPM-Methode Methode Projektmanagement 1 A 2 B 3 C 4 Ende von A ist Voraussetzung für Beginn von B und C S 1 A 3 A und B besitzen gemeinsames Anfangsereignis Scheinvorgang S 2 B (Zeitdauer von S == 0) A 1 4 S B 2 3 C D 5 6 A, B, C, D: C nach Ende von A und B D nach Ende von B Scheinvorgang S für gemeinsames Ende von A, B und Start von C mit (3, 4) 50
51 Netzplantechnik: CPM-Methode Methode Projektmanagement B 4 A1 1 2 C A2 5 Beginn von B im Verlaufe von A=A1+A2 3 D 6 C 1 A 3 Netzpläne sind zyklenfrei (ex. keine gerichteten Zyklen) 2 B Zusammenfassung: 1. Kanten sind eindeutig definierte Vorgänge 2. Knoten sind nicht eindeutig definierte Ereignisse 3. Zur eindeutigen Darstellung sind Scheinvorgänge zu verwenden 51
52 Netzplantechnik: CPM-Methode Methode Projektmanagement Analyse in 3 Stufen: 1. Strukturanalyse 2. Zeitanalyse 3. Kosten- und Kapazitätsanalyse (1) Strukturanalyse in 3 Schritten: Erstellen der Vorgangsliste Entwurf des Netzplans Kontrolle der Grundregeln Vorgangsliste: 1. Welche Vorgänge sind vor dem betrachteten Vorgang abzuschließen? (Vorgänger) 2. Welche Vorgänge können unmittelbar nach dem betrachteten begonnen werden? (Nachfolger) 3. Welche Vorgänge können gleichzeitig zum betrachteten ablaufen? (unabhängig) 4. Welche Vorgänge können zu anderen überlappt ablaufen? 52
53 Netzplantechnik: CPM-Methode Methode Projektmanagement Beispiel Brückenbau Zs1 Ms Zs2 Vorgangsliste: E1 Pf1 Pf2 E2 Vorgang A allgemeine Planung B Fertigung Einzelteile C Herstellung Endlager E1 D Herstellung Endlager E2 E Herstellung Pfeiler Pf1 F Herstellung Pfeiler Pf2 G Montage Zwischenstück Zs1 H Montage Zwischenstück Zs2 I Montage Mittelstück Ms K Einschwimmen Mittelstück L Eröffnung Direkter Vorgänger - A A A A A B,C,E B,D,E B E,F,I G,H,K 53
54 Netzplantechnik: CPM-Methode Methode Projektmanagement Entwurf des Netzplans: (Beziehungsschema) aktueller Vorgang A B C D E F G H I K L A x x x x x B x x x C x Vorgänger D E F x x x x x G x H x I x K x L 54
55 Netzplantechnik: CPM-Methode Methode Projektmanagement Zeichnen Sie zur gegebenen Vorgangsliste und zum angegebenen Beziehungsschema den daraus folgenden Netzplan 5 G C S E 4 S 1 A 2 B F 3 I 8 K 9 L 10 D 6 S S H 7 55
56 Netzplantechnik: CPM-Methode Methode Projektmanagement (2) Zeitanalyse a) Bestimmen der Vorgangsdauer b) progressive und retrograde Zeitrechnung c) Ermitteln des kritischen Pfades und der Zeitreserven (a)vorgangsdauer bei SW-Projekten durch geeignete Schätzverfahren ermitteln (b) Zeitrechnung: frühest mögliche Beginn- und Abschlusszeiten spätest mögliche Beginn- und Abschlusszeiten Puffer- und Schlupfzeiten der Vorgänge 4 Elementare Zeitpunktgrößen: FA(i,j) früheste Anfangszeit SA(i,j) späteste Anfangszeit FE(i,j) früheste Endezeit SE(i,j) späteste Endezeit 56
57 Netzplantechnik: CPM-Methode Methode Projektmanagement Berechnung der Ereigniszeiten frühestmöglicher Zeitpunkt FZ(i) des Ereignis i = zeitlängster Weg von Start bis i; Addition der Vorgangszeiten auf dem Pfad von Start bis i spätesterlaubter Zeitpunkt SZ(i) des Ereignis i = L [zeitlängster Weg von Ziel bis i]; L minimale Gesamtprojektdauer = längster Pfad von Start bis Ziel (L=31) FZ(3) = 12 = D(1,2)+D(2,3) SZ(3) = 19 = L D(5,6) D(3,5) Puffer / Schlupf / Slack-Time: SZ(3) FZ(3) = 7 D(2,3) =
58 Netzplantechnik: CPM-Methode Methode Projektmanagement ( FZ(3) + D(3,5) = 12+8 =20 FZ(5) = max ( FZ(2) + D(2,5) = 5+11 =16 ( FZ(4) + D(4,5) = =27 Kritischer Pfad: ein kritischer Pfad liegt vor, wenn FZ(n) == L frühester Zeitpunkt für letztes Ereignis ist längster Pfad Kritischer Vorgang (i,j) : FZ(i)==SZ(i); FZ(j)==SZ(j) frühest mögliche und spätest mögliche Zeiten fallen zusammen 58
59 Aufgaben - Netzplantechnik Ermitteln Sie zu einer gegebenen Vorgangsliste mit Vorgängerangaben ein Beziehungsschema Erzeugen Sie einen Netzplan und überprüfen Sie die Entwurfsregeln Identifizieren Sie den/die kritischen Pfad/e Ermitteln Sie die freien Kapazitäten Wie ließen sich die freien (Zeit-) Kapazitäten nutzen? Um welchen Preis jeweils? 59
60 5. Elemente des SW-Entwicklungsprozesses a. Prinzipien der SW-Entwicklung b. Problemanalyse c. System-Entwurf d. Prototyp-Entwicklung und Simulation e. Programmentwurf f. Programmtest g. Systemtest und Integration h. Auslieferung i. Wartung j. Auswertung und Verbesserung 60
61 5.a. Prinzipien der SW-Entwicklung Beherrschung der Komplexität Komplexitätsreduktion durch Analyse, Strukturbildung, Architekturentwicklung Beherrschung des Aufwands (Aufwandsreduktion*) durch Modularität, Standardisierung, Objektorientierung, Implementation Hiding, Lokalitätsprinzip Beherrschung der Qualitätsanforderungen Erkennen und Verfolgen allgemeiner und produktspezifischer Qualitätsziele * Aufwandsreduktion Wiederverwendbarkeit 61
62 Qualitätsanforderungen Ziele (Delfs 99 / E1) 5.a Qualitätsmerkmale aus Benutzersicht Funktionserfüllung Effizienz Zuverlässigkeit Benutzbarkeit Sicherheit HW-Effizienz SW-Effizienz Robustheit Fehlertoleranz Qualitätsmerkmale aus Entwicklersicht Erweiterbarkeit Wartbarkeit Portierbarkeit Wiederverwendbarkeit Konfigurierbarkeit/ Skalierbarkeit Entwurfsstabilität Änderbarkeit Testbarkeit Anpassbarkeit Montierbarkeit 62
63 Qualitätsmerkmale (Delfs 99 / E2) 5.a Zwei fundamentale Lehrsätze: Theorem 1: Wiederverwendbarkeit Wartbarkeit Erweiterbarkeit Änderbarkeit Anpassbarkeit "Software-Entwurf muss verständlich sein" Theorem 2: Konfigurierbarkeit Skalierbarkeit Montierbarkeit Wiederverwendbarkeit Wartbarkeit "Software muss modular mit sauberen Schnittstellen sein" ("Software-ICs") 63
64 "Software muss verständlich sein" (aus Delfs 99 / E4) 5.a Schließen der semantischen Lücke (semantic gap) durch verständliche SW-Architektur(en) Problem reale Anwendungswelt "Objekte" mit Eigenschaften, Beziehungen, Funktionalität natürliche Sprache Modell des Problems Modell der Lösung Analysemodell Entwurf / "Bauplan" ausreichend mächtige, ausreichend präzise, ausreichend abstrakte, ausreichend anschauliche Modellierungssprache Lösung Programm / "Werkplan" Variablen, Datenstrukturen Prozeduren, Funktionen, Operatoren Klassen, Instanzen, Instanzvariablen, Operationen, Polymorphismus, Klassenhierarchien, Vererbung, (4GL-, objektorientierte) Programmiersprache 64
65 Begriffe 5.a Modell: Muster, Vorbild, Entwurf oder Nachbildung in kleinerem Maßstab; Typ, Ausführungsart eine Fabrikats vereinfachte Darstellung der Funktion eines Gegenstands oder des Ablaufs eines Sachverhalts, die eine Untersuchung od. Erforschung erleichtert oder erst möglich macht Modul: austauschbares, komplexes Teil eines Gerätes od. einer Maschine, das eine geschlossene Funktionseinheit bildet unabhängig voneinander realisierbare und in ihrem Zusammenwirken überschaubare Einzelbausteine (Moduln) Modularisierung: ein Gesamtsystem in Moduln unterteilen und deren Funktionen, ihre Beziehungen zueinander und ihre Schnittstellen beschreiben 65
66 Software muss modular mit sauberen Schnittstellen sein 5.a Beherrschung der Komplexität Komplexitätsreduktion durch Analyse, Strukturbildung, Architekturentwicklung Systemkomponente1 Schnittstelle Systemumgebung System Systemkomponente3 Beziehung Systemkomponente2 Software-Architektur aus Komponenten und Beziehungen 66
67 Beherrschung der Komplexität 5.a Komplexitätsreduktion durch Analyse, Strukturbildung, Architekturentwicklung Komponente 2.1 Komponente 2.2 Komponente 2.3 Schicht 2 Komponente 1.1 Komponente 1.2 Komponente 1.3 Schicht 1 Komponente 0.1 Komponente 0.2 Komponente 0.3 Schicht 0 Komp. A benutzt Komp. B Schicht A benutzt Schicht B geschichtete Architektur 67
68 Schichtenarchitektur 5.a Schichtung abstrakter 'Maschinen' höhere Schicht benutzt niedrigere Implementierung der höheren Schicht mit den Komponenten der unterlagerten Schicht(en) Musterbeispiel Rechnerarchitektur (HW-Architektur, Sprachhierarchie) 68
69 Modularisierung - Übersicht 5.a Zerlegen eines Systems in Moduln entsprechend dem intrinsischen Modularisierungskonzept der Implementierungsebene (-Sprache): Abstraktionsformen: funktionale Abstraktion, Datenabstraktion, Klassenbildung Modultypen: Funktionsmoduln (Sammlungen log. zusammengehöriger Funktionen) Datenmoduln (Sammlungen log. zusammengehöriger Daten / Datendefinitionen) abstrakte Datenstrukturen (Abstraktion vom Elementtyp der D.-Struktur / z.b. Puffer, Keller, Warteschlange, Baum, Liste) + Zugriffsfunktionen abstrakte Datentypen (Beschreibung eines Datenstrukturtyps, Nutzung in Deklarationen von Datenstrukturen Instanzerzeugung) generische abstrakte Datentypen (Abstraktion vom Elementtyp, u. zusätzliche Parameter z.b. für Skalierung u. Dimensionierung) Klassenmoduln / Mengen von Objektklassen (OOP) Modul auch pragmatisch: Funktionsbaustein, Function Block, (betriebliche / Automatisierungs-) Funktion Planen / Entwerfen der Schnittstellen nach Problem-Anforderungen und innerer Logik der entwickelten Moduln (evtl. über explizite Anforderungen hinaus) Normierung und Standardisierung von Schnittstellen 69
70 Modularisierung - Übersicht Abstraktionshierarchie: Klasse generischer abstrakter Datentyp abstrakter Datentyp Abstraktion abstrakte Datenstruktur Datenstruktur(-Instanz) 70
71 5.b. Problemanalyse 1. Analysieren durch Modellieren der Problemsituation ( Modell) 2. Auswahl von Modellierungsmethoden hier: Semantische Datenmodellierung mit Entity-Relationship-Diagrammen (Ziel: Ableiten eines Relationenschemas / Datenbankschemas) Strukturierte Analyse (SA) Datenflussdiagramme (Kontextdiagramm + hierarchische Verfeinerungen) Zustandsdiagramme Entscheidungstabellen Datenkatalog Real-Time-Analyse (RT) Unified Modelling Language (UML) Use-Case-Diagramm (Akteure, Szenarios) Klassendiagramm (Klassen, Beziehungen) Paket-Diagramm (Strukturierung der Darstellung) Kollaborationsdiagramme (Zusammenwirken der Komponenten) Aktivitätsdiagramm (Ablaufmöglichkeiten) Sequenzdiagramme (Objekte, Interaktionen) Zustandsübergangsdiagramm (Internes Verhalten von Objekten) Komponentendiagramm (Innere Struktur der Objekte) Verteilungsdiagramm (Einbettung der Objekte in eine Umgebung) 71
72 5.b.1 Analysieren durch Modellieren der Problemsituation [Rumbaugh 91 / f.8.1] Benutzer Entwickler Manager Erzeuge Anforderungen Analyse Problembeschreibung Anwenderbefragung Bereichswissen Erfahrungswissen Erzeuge Modelle Objektmodell Dynamikmodell Funktionsmodell Entwurf Darstellung mit SA-Elementen 72
73 5.b.1 Analysieren durch Modellieren der Problemsituation Anforderungen an ein Analysewerkzeug / Modellierungswerkzeug Anschaulichkeit, intuitives Verständnis für Anwender und Leser grafische Notation, grafische Elemente, Übersichten ausreichende Mächtigkeit Vorrat von Darstellungselementen, Symbolen; Ausdruckskraft Abdecken der verschiedenen Modellierungsaspekte ausreichende Präzision Klarheit der Darstellung, Eindeutigkeit, Ansatz für nachfolgende Prozessschritte ausreichende Abstraktion Möglichkeit zur hierarchischen Abstraktion, Gliederung 73
Klausur Software Engineering für WI (EuI)
Autor: Prof. Dr. Bernhard Humm, FB Informatik, FH Darmstadt Datum: 14. Februar 2006 Klausur Software Engineering für WI (EuI) Ihr Name: Ihre Matrikelnummer Erreichte Punkte (von insgesamt 57 Punkten):
MehrKlausur Software-Engineering SS 2005 Iwanowski 23.08.2005
Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005 Hinweise: Bearbeitungszeit: 90 Minuten Erlaubte Hilfsmittel: im Anhang, sonst keine Bitte notieren Sie Ihre Antworten ausschließlich auf dem Aufgabenblatt!
MehrSoftware- Entwicklungsaktivitäten und Vorgehensmodelle. Lebenszyklusmodell
1. Vorgehensmodelle Software- Entwicklungsaktivitäten und Vorgehensmodelle a) Lebenszyklusmodell (Life- Cycle- Modell) b) V- Modell c) Wasserfallmodell d) Modifiziertes Wasserfallmodell e) Iterative Modelle
MehrSoftwaretechnik. Fomuso Ekellem WS 2011/12
WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering
MehrUse Cases. Use Cases
Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben
MehrSoftware-Engineering
FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 2: Grundbegriffe und Prinzipien FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 2 Grundbegriffe
MehrProjektarbeit. 2003 Eberhard Neef - 2 - Nee Seite 1
Nee Seite 1 1. Projektorganisation...2 1.1. Projektdefinition...2 1.2. Projektauslösung...2 1.3. Vorstudie...2 1.3.1. Zweck der Vorstudie und Aufgaben...2 1.3.2. Problemanalyse...2 1.3.3. Ziele...3 1.3.4.
MehrOrientierte Modellierung mit der Unified Modeling Language
UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?
MehrSoftwaretechnik (Allgemeine Informatik) Überblick
Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6
MehrKapitel 2: Der Software-Entwicklungsprozess
Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken
MehrObjektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt
Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse
MehrAgile Vorgehensmodelle in der Softwareentwicklung: Scrum
C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was
MehrWirtschaftsinformatik 2 Modellierung betrieblicher Informationssysteme - MobIS
Wirtschaftsinformatik 2 Modellierung betrieblicher Informationssysteme - MobIS (theoretische Aspekte der Informationsmodellierung) 3. Vorlesung 23.04.2007 Informationsmodelle Phasen der Softwareentwicklung:
MehrAbschnitt 16: Objektorientiertes Design
Abschnitt 16: Objektorientiertes Design 16. Objektorientiertes Design 16 Objektorientiertes Design Informatik 2 (SS 07) 610 Software-Entwicklung Zur Software-Entwicklung existiert eine Vielfalt von Vorgehensweisen
MehrÜbungsaufgaben zum Software Engineering: Management
Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie
MehrSome Software Engineering Principles
David L. Parnas: Some Software Engineering Principles Marco Oppel 30.06.2004 Seminar Software-Architektur Institut für Informatik Humboldt Universität zu Berlin 1 Problemstellung Software Engineering Multi-Personen
MehrEINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.
EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG
MehrVBA-Programmierung: Zusammenfassung
VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung
MehrÜbung 4. Musterlösungen
Informatik für Ökonomen II HS 2010 Übung 4 Ausgabe: 18.11.2010 Abgabe: 25.11.2010 Musterlösungen Schreiben Sie Ihre Namen und Ihre Matrikelnummern in die vorgesehenen Felder auf dem Deckblatt. Formen Sie
MehrGeschäftsprozesse: Modellierung und Analyse
Geschäftsprozesse: Modellierung und Analyse. Ausgangssituation 2. Begriffe 3. Modellierungsmethoden 4. Modellarten 5. orgehensprinzipien 6. Analyse 7. Werkzeuge Seite Klassische Unternehmensmodelle Unternehmensmodell:
MehrUnified Modeling Language (UML)
Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine
MehrGrundlagen Software Engineering
Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der
MehrObjektorientierte Programmierung OOP
Objektorientierte Programmierung OOP Objektorientierte Programmierung OOP Ronja Düffel WS2012/13 08. Oktober 2013 Objektorientierte Programmierung OOP Objektorientierte Programmierung Objektorientierte
MehrDatenbankmodelle 1. Das Entity-Relationship-Modell
Datenbankmodelle 1 Das Entity-Relationship-Modell Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle ER Modell - 2 Was kann modelliert werden?
MehrSoftware-Engineering
SWE5 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 5: Systementwurf SWE5 Slide 2 Systemanalyse vs. Softwareentwurf Systemanalyse beschreibt das System der Anwendung, für das eine Aufgabe
MehrKlausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement
Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. K.-P. Fähnrich, Prof. H.-G. Gräbe, T. Riechert Institut für Informatik Sommersemester 2012 Allgemeine Bemerkungen
MehrProgrammieren Formulierung eines Algorithmus in einer Programmiersprache
Zum Titel der Vorlesung: Programmieren Formulierung eines in einer Programmiersprache Beschreibung einer Vorgehensweise, wie man zu jedem aus einer Klasse gleichartiger Probleme eine Lösung findet Beispiel:
MehrER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung
ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung Datenbank-Praktikum SS 2010 Prof. Dr. Georg Lausen Florian Schmedding ER-Modell: Wiederholung Entitäten E Beziehungen B Attribute
MehrDie Softwareentwicklungsphasen!
Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.
MehrSoftwareentwicklungspraktikum Sommersemester 2007. Feinentwurf
Softwareentwicklungspraktikum Sommersemester 2007 Feinentwurf Auftraggeber Technische Universität Braunschweig
MehrWintersemester 2010/2011 Rüdiger Westermann Institut für Informatik Technische Universität München
Informatik 1 Wintersemester 2010/2011 Rüdiger Westermann Institut für Informatik Technische Universität München 1 0 Allgemeines Zielgruppen Siehe Modulbeschreibung Studierende anderer (nicht Informatik)
MehrWillkommen zum DBS I Praktikum!
Willkommen zum DBS I Praktikum! Oliver Berthold Frank Huber Heiko Müller Lehr- und Forschungseinheit Datenbanken und Informationssysteme Übungsaufgaben Ausgabe Montags (i.d.r. aller 2 Wochen) erste Aufgabe
MehrÜbungsklausur vom 7. Dez. 2007
Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement
MehrSoftware Engineering
Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,
MehrSoftware-Engineering SS03. Zustandsautomat
Zustandsautomat Definition: Ein endlicher Automat oder Zustandsautomat besteht aus einer endlichen Zahl von internen Konfigurationen - Zustände genannt. Der Zustand eines Systems beinhaltet implizit die
MehrInhaltsverzeichnis. 1. Fragestellung
Inhaltsverzeichnis 1. Fragestellung... 1 2. Herleitung zum Thema... 1 3. Das Entity Relationship Modell (ERM)... 2 4. Praktisches Beispiel zum ERM... 7 5. Anhang...Fehler! Textmarke nicht definiert. 1.
MehrKapitel 3: Hörsaalbeispiel Klassendiagramm (Analysesicht)
Kapitel 3: Hörsaalbeispiel Klassendiagramm (Analysesicht) Anforderungen In einer Hochschulverwaltung sind mehrere Personengruppen tätig. Die Hochschule hat Angestellte, die Professoren, Labor-Ingenieure,
MehrAbschlussklausur Geschäftsprozessmodellierung und Workflowmanagement
Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement (Wintersemester 2007/2008, Freitag, 08.02.2008, Leo18) Es können maximal 120 Punkte erreicht werden. 1 Punkt entspricht etwa einer Minute
MehrWS 2002/03. Prof. Dr. Rainer Manthey. Institut für Informatik III Universität Bonn. Informationssysteme. Kapitel 1. Informationssysteme
Informationssysteme Informationssysteme WS 2002/03 Prof. Dr. Rainer Manthey Institut für Informatik III Universität Bonn 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 DB und/oder IS: terminologischer
MehrDas Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin
Fragestellungen: Warum reicht das Lastenheft nicht aus? Was kann ich mit dem Lastenheft machen? Was unterscheidet das Pflichtenheft vom Lastenheft? Was gehört zum Auftragsumfang einer Individualsoftware?
MehrEinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2
EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2
MehrSoftware Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003
Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen
MehrInformationswirtschaft II Rational Unified Process (RUP)
Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das
MehrInformationswirtschaft II
Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe
MehrProgrammierparadigmen. Programmierparadigmen. Imperatives vs. objektorientiertes Programmieren. Programmierparadigmen. Agenda für heute, 4.
Agenda für heute, 4. Mai, 2006 Programmierparadigmen Imperative Programmiersprachen In Prozeduren zusammengefasste, sequentiell ausgeführte Anweisungen Die Prozeduren werden ausgeführt, wenn sie als Teil
MehrUniversität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I
Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Softwaretechnik I Wintersemester 2015 / 2016 www.ias.uni-stuttgart.de/st1 st1@ias.uni-stuttgart.de
MehrÜbungen zur Softwaretechnik
Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se
MehrArchitektur und Qualität. Tjard Köbberling
Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur
MehrProfilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken
Profilbezogene informatische Bildung in den Klassenstufen 9 und 10 Schwerpunktthema Robby Buttke Fachberater für Informatik RSA Chemnitz Fachliche Einordnung Phasen relationaler Modellierung Fachlichkeit
MehrER-Modell. Entity-Relationship-Model
+ ER-Modell Entity-Relationship-Model + Was ist ein Modell? Worte/Zitat aus einem Physikbuch: "Modelle sind also Vorstellungshilfen und Wirklichkeitshilfen, nicht die Wirklichkeit selbst." (Metzler Physik).
MehrKlausur Softwaretechnik 3 22. Feb. 2008
Klausur Softwaretechnik 3 22. Feb. 2008 Hinweise Bevor Sie mit der Bearbeitung der Aufgaben beginnen, müssen Sie auf allen Blättern Ihren Namen und Ihre Matrikelnummer eintragen. Prüfen Sie Ihre Klausur
MehrÜbungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin)
Übungsblatt 4 Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin) Die Saartal Linien beauftragen Sie mit dem Entwurf der Datenstrukturen für ein Informationssystem. Dieses soll zur Verwaltung
MehrSoftware Engineering I
Vorlesung Software Engineering I Dynamische Basiskonzepte 2 Kontrollstrukturen Aktivitätsdiagramme Sequenzdiagramme 1 Basiskonzepte Beschreiben die feste Struktur des Systems, die sich während der Laufzeit
MehrPRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr -
PRÜFUNG FÜR ELEKTROINGENIEURE Softwaretechnik I Musterlösung SS 12 - Ohne Gewähr - LfdNr. Thema Punkte Zeitbedarf in min 1 Analyse und Entwurf 15 30 2 Basistechniken und Test 15 30 3 Projektmanagement
Mehr16 Architekturentwurf Einführung und Überblick
Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software
Mehr1. Modellierung einer Weinhandlung mit der Strukturierten Analyse (SA) 2. Modellierung einer Kassenbuchverwaltung mit der Strukturierten Analyse (SA)
1 Übungen zu Software-Engineering 1. Modellierung einer Weinhandlung mit der Strukturierten Analyse (SA) 2. Modellierung einer Kassenbuchverwaltung mit der Strukturierten Analyse (SA) 3. Modellierung eines
Mehr3.2,,Eichung von Function Points (Berichtigte Angabe)
I N S T I T U T E F O R R E A L - T I M E C O M P U T E R S Y S T E M S TECHNISCHE UNIVERSIT ÄT MÜNCHEN P R O F E S S O R G. F Ä R B E R Software Engineering 3. Übung 22.05.2003 3.2,,Eichung von Function
MehrUse Cases. Die Sicht des Nutzers. Fortgeschrittenenpraktikum SS 2004
Use Cases Die Sicht des Nutzers Fortgeschrittenenpraktikum SS 2004 Gunar Fiedler Lehrstuhl für Technologie der Informationssysteme Kontakt: fiedler@is.informatik.uni-kiel.de Use Cases 2 Was ist ein Use
MehrDr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht
Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur UML-Klassendiagramme als Werkzeug im Unterricht Blitzlicht? In welcher Programmiersprache(n) unterrichten Sie?? In welchem Umfang unterrichten Sie Objektorientierung??
MehrDiplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008
Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen
MehrKapitel 04 Strukturiertes Entity-Relationship-Modell. 4 Strukturiertes Entity-Relationship- Modell
Kapitel 04 Strukturiertes Entity-Relationship-Modell 4 Strukturiertes Entity-Relationship- Modell 4 Strukturiertes Entity-Relationship-Modell...1 4.1 Erste Verbesserung...4 4.2 Objekttypen in SERM...6
MehrRequirements Engineering für IT Systeme
Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein
MehrKurzanleitung. Zuordnung eines Moodle-Kurses in TUMonline
Kurzanleitung Zuordnung eines Moodle-Kurses in TUMonline Inhalt 1 Allgemeine Informationen... 2 2 Kategorie elearning zuordnen... 2 3 Wo ist die Kategorie nach der Zuteilung zu finden?... 4 4 Wann wird
MehrRequirements Engineering I
Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen
MehrSoftware Engineering. Sommersemester 2012, Dr. Andreas Metzger
Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle
MehrEberhard Lehmann: Projekte im Informatik-Unterricht Software Engineering, Ferd. Dümmlers Verlag, Bonn 1995. Inhaltsverzeichnis.
3 Eberhard Lehmann: Projekte im Informatik-Unterricht Software Engineering, Ferd. Dümmlers Verlag, Bonn 1995 Inhaltsverzeichnis Vorwort 5 1. Komplexe Software - Projekte - Software-Engineering 7 1.1 Komplexe
MehrKlausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007
Fachhochschule Bonn-Rhein-Sieg University of Applied Sciences Fachbereich Informatik Prof. Dr. Peter Becker Klausur WS 2006/07 Programmiersprache Java Objektorientierte Programmierung II 15. März 2007
MehrIntegration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.
Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung
MehrFachbericht zum Thema: Anforderungen an ein Datenbanksystem
Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank
MehrProzess-Modelle für die Softwareentwicklung
Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell
MehrAllgemeines zu Datenbanken
Allgemeines zu Datenbanken Was ist eine Datenbank? Datensatz Zusammenfassung von Datenelementen mit fester Struktur Z.B.: Kunde Alois Müller, Hegenheimerstr. 28, Basel Datenbank Sammlung von strukturierten,
MehrVorlesung Betriebstechnik/Netzplantechnik Operations Research
Vorlesung Betriebstechnik/Netzplantechnik Operations Research Organisation Agenda Übungen Netzplantechnik GANTT-Diagramme Weitere Übungen 2 Übungen 3 weitere Übungen Nr. Vorgang Dauer AOB 1 Kickoff 2-2
MehrModellierung verteilter Systeme Grundlagen der Programm und Systementwicklung
Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung Wintersemester 2009/10 Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. K. Spies, Dr. M. Spichkova, L. Heinemann, P.
MehrSuche schlecht beschriftete Bilder mit Eigenen Abfragen
Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere
Mehr17 Architekturentwurf Vorgehen und Dokumentation
17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen
MehrDatenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1
Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.
MehrWir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen. Wir bringen Qualität. Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen
Was bedeutet es, ein Redaktionssystem einzuführen? Vorgehensmodell für die Einführung eines Redaktionssystems Die Bedeutung Fast alle Arbeitsabläufe in der Abteilung werden sich verändern Die inhaltliche
MehrKapitel 3: Einführung Projektmanagement
: : : : : : : : : : : : : : : : : : : : : Kapitel 3: Einführung Projektmanagement Dr.-Ing. Bastian Koller, Axel Tenschert koller@hlrs.de, tenschert@hlrs.de : : : : : : : : : : : : : : : : : : : : : Kapitel
MehrSoftwaretechnologie -Wintersemester 2011/2012 - Dr. Günter Kniesel
Übungen zur Vorlesung Softwaretechnologie -Wintersemester 2011/2012 - Dr. Günter Kniesel Übungsblatt 3 - Lösungshilfe Aufgabe 1. Klassendiagramme (9 Punkte) Sie haben den Auftrag, eine Online-Videothek
MehrHow to do? Projekte - Zeiterfassung
How to do? Projekte - Zeiterfassung Stand: Version 4.0.1, 18.03.2009 1. EINLEITUNG...3 2. PROJEKTE UND STAMMDATEN...4 2.1 Projekte... 4 2.2 Projektmitarbeiter... 5 2.3 Tätigkeiten... 6 2.4 Unterprojekte...
MehrSoftwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler
Übungen zur Vorlesung Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungsblatt 4 Lösungshilfe. Aufgabe 1. Zustandsdiagramm (8 Punkte) Geben Sie ein Zustandsdiagramm für
MehrÜbungsblatt 4: Requirements Engineering (2) (für die Übungswoche 14.11. 18.11.2011)
Übungsblatt 4: Requirements Engineering (2) (für die Übungswoche 14.11. 18.11.2011) Daueraufgabe: Fünf in Fünf Präsentationsaufgabe. Bereiten Sie eine fünfminütige Präsentation vor, in der Sie die fünf
MehrInformationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:
Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät
MehrVorlesung Nr.9: Der Inhalt
Vorlesung Nr.9: Der Inhalt Integrierte IS. Beispiel Die Prinzipien der Projektierung und Realisierung eines IS fuer Verwaltung Die funktionelle Untersysteme eines Unternehmens. Methoden für Projektierung
Mehr6. Programmentwicklung
6. Programmentwicklung Fertigungsprozess Qualitativ hochwertige Software ist ein Industrieprodukt -> Methoden der Industrie übertragen auf der Herstellprozess -> Herstellprozess gliedert sich in Phasen
MehrSoftwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler
Übungen zur Vorlesung Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungsblatt 3 Lösungshilfe Aufgabe 1. Klassendiagramme (9 Punkte) Sie haben den Auftrag, eine Online
MehrProjektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung
Projektmanagement Vorlesung von Thomas Patzelt 9. Vorlesung 1 Pläne Kein Plan überlebt die erste Feindberührung - Feldmarschall Helmuth von Moltke Prognosen sind schwierig, besonders wenn sie die Zukunft
MehrSDD System Design Document
SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen
MehrSchulinternes Curriculum für Informatik (Q2) Stand April 2015
Schulinternes Curriculum für Informatik (Q2) Stand April 2015 Unterrichtsvorhaben Q2-I Thema: Modellierung und Implementierung von Anwendungen mit dynamischen, nichtlinearen Datenstrukturen Modellieren
MehrKonzepte der Informatik
Konzepte der Informatik Vorkurs Informatik zum WS 2011/2012 26.09. - 30.09.2011 17.10. - 21.10.2011 Dr. Werner Struckmann / Christoph Peltz Stark angelehnt an Kapitel 1 aus "Abenteuer Informatik" von Jens
MehrSoftwaretechnik. Fomuso Ekellem WS 2011/12
WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von
MehrHandbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken
Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen
MehrDatenbanken I - Übung 1
Datenbanken I - Übung 1 Oktober, 2010 1 von 11 Datenbanken I Lernkontrolle Beantworten Sie folgende Fragen (nach Möglichkeit ohne nachzuschlagen): Was bezeichnet man als Datenredundanz? Wieso führt Datenredundanz
Mehrextreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?
MehrSystemanalyse. - Seminar für AI/DM 3 im Wintersemester 2004/05 -
Systemanalyse - Seminar für AI/DM 3 im Wintersemester 2004/05 - Prof. Dr. Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern,
MehrPHP Kurs Online Kurs Analysten Programmierer Web PHP
PHP Kurs Online Kurs Analysten Programmierer Web PHP Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses PHP Modul 1 - Einführung und Installation PHP-Umgebung Erste Lerneinheit Introduzione
Mehr09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)
Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)
MehrVorlesung Programmieren
Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)
MehrKonsolidierung und Neuimplementierung von VIT. Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt
Konsolidierung und Neuimplementierung von VIT Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt Inhaltsverzeichnis 1 Was ist der Kontext?... 1 2 VIT: Ein sehr erfolgreiches
Mehra) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. 1 zeigt eine mögliche Lösung. * * * Aufbau 1..
Software Engineering I Musterlösungen zur Klausur vom 3.7.2004 Aufgabe a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Abb. zeigt eine mögliche Lösung. Turnier sportart
Mehr