Prozess-Modelle. Modelle. Einführung in UML
|
|
- Damian Diefenbach
- vor 8 Jahren
- Abrufe
Transkript
1 Modelle Prozess-Modelle Wasserfallmodell V-Modell Prototypenmodell Evolutionäres/inkrementelles Modell Objektorientiertes Modell Nebenläufiges Modell Spiralmodell Einführung in UML Klassendiagramme Anwendungsfalldiagramme
2 Einführung Prozess-Modelle legen den organisatorischen Rahmen einer Software-Entwicklung fest Prozess-Modelle legen folgendes fest: Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasenkonzepte) Durchzuführende Aktivitäten Definition der Teilprodukte (einschließlich Layout und Inhalt) Fertigungskriterien (Wann ist ein Teilprodukt fertiggestellt) Notwendige Mitarbeiterqualifikation Einzuhaltende Standards, Richtlinien und Werkzeuge 2
3 Prozess-Modelle Wasserfallmodell V-Modell Prototypenmodell Evolutionäre/inkrementelle Modell Objektorientierte Modell Nebenläufige Modell Spiralmodell 3
4 Das Wasserfall-Modell (1) System- Anforderungen Software- Anforderungen Analyse Entwurf Codierung Testen Betrieb 4
5 Das Wasserfall-Modell (2) Jede Aktivität ist in der richtigen Reihenfolge und in voller Breite durchzuführen Am Ende jeder Aktivität steht ein fertiggestelltes Dokument (Dokumentengetriebenes Modell) Sequentielle Abfolge der Aktivitäten (Keine Überlappung von Aktivitäten) Iterationen sind nur zwischen zwei aufeinanderfolgenden Stufen erlaubt 5
6 Das Wasserfall-Modell: Bewertung Vorteile Einfach, verständlich Geringer Management-Aufwand Disziplinierter, kontrollierbarer und sichtbarer Prozessablauf Nachteile Die Sequentialität und volle Breite der Entwicklungsschritte oft nicht sinnvoll Gefahr einer Überbewertung der Dokumentation Risiken werden zu wenig berücksichtigt Benutzerbeteiligung nur bei Anforderungen und im Betrieb Möglichkeit von Feedback kaum gegeben 6
7 Das V-Modell (1) Validierung Anforderungs- Definition Anwendungsszenarien Abnahmetest Grobentwurf Testfälle Systemtest Verifikation Feinentwurf Testfälle Integrationstest Modul- Implementation Testfälle Modultest 7
8 Das V-Modell (2) Erweiterung des Wasserfall-Modells Berücksichtigung der Qualitätssicherung Verifikation: Überprüfung der Übereinstimmung zwischen Software- Produkt und Spezifikation Validierung: Überprüfung der Eignung eines Produktes bezogen auf Einsatzzweck Submodelle im V-Modell: PM: Projektmanagement SE: Systemerstellung QS: Qualitätssicherung KM: Konfigurationsmanagement 8
9 Das V-Modell: Submodelle PM Projekt planen und kontrollieren Voraussetzungen schaffen und SEU bereitstellen Plandaten Istdaten SEU Istdaten QS- Anforderungen vorgeben SEU SE Produkt entwickeln SEU Konfigurationsstruktur Plandaten Plandaten Plandaten Istdaten Istdaten SEU Produktstruktur planen QS- Ergebnis Produkte prüfen QS-Anforderung Produkt Rechte Produkte/ Rechte verwalten QS Produkt KM 9
10 Das V-Modell: Rollen Submodell Manager Verantwortliche Durchführende PM Projektmanager Projektleiter Rechtsverantwortlicher Controller Projektadministrator SE Projektmanager IT-Beauftragter Anwender Projektleiter Systemanalytiker Systemdesigner SW-Entwickler HW-Entwickler Technischer Autor SEU-Betreuer Datenadministrator IT-Sicherheitsbeauftragter Datenschutzbeauftragter Systembetreuer QS Q-Manager QS-Verantwortlicher Prüfer KM KM-Manager KM-Verantwortlicher KM-Administrator 10
11 Das V-Modell: Bewertung Vorteile Integrierte, detaillierte Darstellung von SE, QS, KM und PM Generisches Vorgehensmodell mit definierten Möglichkeiten zur Anpassung an projektspezifischen Anforderungen Gut geeignet für große Projekte Nachteile Die Vorgehenskonzepte, die für große Projekte geeignet sind werden unreflektiert auf andere Projekte übertragen Für kleine und mittlere Softwareentwicklungen führt das V- Modell zu einer unnötigen Bürokratie Die im V-Modell definierten Rollen (bis zu 25) sind für gängige Softwareentwicklungen nicht realistisch Ohne geeignete Werkzeug-Unterstützung ist das V-Modell nicht handhabbar 11
12 Das Prototypen-Modell Probleme bei der Verwendung des Wasserfall- und V-Modells Auftraggeber und Endbenutzer können ihre Anforderungen an ein Software-Produkt oft nicht explizit und vollständig formulieren In der Entwicklungsphase ist ein Austausch zwischen Anwendern und Software-Entwicklern notwendig Für manche Anforderungen gibt es unterschiedliche Lösungen, die mit dem Auftraggeber diskutiert werden müssen Die Realisierbarkeit mancher Anforderungen kann theoretisch nicht garantiert werden und muss durch Experimente ermittelt werden Für die Projektakquisition muss der (potentielle) Auftraggeber von der Software-Lösung überzeugt werden Lösung: Prototypen-Modell Prototypen dienen dazu, relevante Anforderungen oder Entwicklungsprobleme zu klären Prototypen stellen Diskussionsbasis dar und helfen bei der Entscheidungsfindung Prototypen dienen dazu, Experimente durchzuführen und damit erste Erfahrungen mit der Anwendung zu sammeln 12
13 Das Prototypen-Modell Prototyping Unterstützt die frühzeitige Erstellung ablauffähiger Modelle (Prototypen) des zukünftigen Systems Dient zur Ermittlung der Realisierbarkeit von Anforderungen Arten von Prototypen Demonstrationsprototyp: Stellt ein mögliches Aussehen einer geplanten Software-Lösung dar Dient zur Auftragsakquisition (Wird i.a. nach Erfüllung der Aufgabe weggeworfen) Prototyp im engeren Sinne: Realisiert Teile der Funktionalität (z.b. Benutzerschnittstelle) Dient zur Analyse des Anwendungsbereichs Labormuster: Demonstriert technische Umsetzbarkeit der Anforderungen Dient zur Beantwortung konstruktionsbezogener Fragen und Alternativen Pilotsystem: Ist Kern des Produktes Wird in Zyklen zum Endprodukt weiterentwickelt 13
14 Das Prototypen-Modell: horizontale vs. Vertikale Prototypen Benutzeroberfläche Anwendung Horinzontale Prototypen Netzanbindung Datenhaltung Systemsoftware Vertikale Prototypen Horizontale Prototypen: Realisierung spezifischer Ebenen des Systems Vertikale Prototypen: Realisierung ausgewählter Teile des Zielsystems durch alle Ebenen hindurch 14
15 Vorteile Das Prototypen-Modell: Bewertung Reduzierung von Entwicklungsrisiken durch frühzeitige Verwendung von Prototypen Verbesserung der Planung von Software-Entwicklungen Starke Rückkopplung mit dem Endbenutzer bzw. Auftraggeber Förderung der Kreativität bei der Ermittlung von Alternativen für die Problemlösung Nachteile Aufwand für die Entwicklung von Prototypen Aufwand für Prototypentwicklung oft vertraglich schwer zu fassen Gefahr der Weiterverwendung von (Wegwerf-)Prototypen 15
16 Das evolutionäre Modell Nullversion X:=0 Definieren Version X X:=X+1 Änderungen Partielles Modell Änderungen Entwerfen Version X partielle Architektur Implement. Version X Produkt Version X Wünsche Einsetzen Version X 16
17 Das evolutionäre Modell Kern bzw. Mussanforderungen des Auftraggebers definieren Produktkern Produktkern wird als erstes entworfen und entwickelt (Nullversion) Erfahrungen mit Nullversion führen zu neuen Anforderungen aus denen eine neue Version entwickelt wird Merkmale des evolutionären Modells Stufenweise Entwicklung des Produkts, gesteuert durch Erfahrung von Endbenutzern Gut geeignet, wenn der Auftraggeber seine Anforderungen noch nicht vollständig überblickt Die Entwicklung im evolutionären Modell ist Codegetrieben: Der Fokus liegt jeweils auf lauffähigen Teilprodukten 17
18 Das evolutionäre Modell: Bewertung Vorteile Einsatzfähige Produkte in kurzen Zeitabständen Lässt sich mit dem Prototypen-Modell kombinieren Auswirkungen des Produkteinsatzes lassen sich untersuchen und die gewonnene Erfahrungen werden in der folgenden Version berücksichtigt Die Richtung der Entwicklung ist leichter steuerbar: statt einem Ergebnis gibt es mehrere Zwischenergebnisse Nachteile Falls in der Nullversion Kernanforderungen übersehen wurden muss die Systemarchitektur u.u. vollständig überarbeitet werden Die Nullversion kann sich als zu unflexibel für spätere Anpassungen erweisen 18
19 Das Inkrementelle Modell Variation des evolutionären Modells: Die Anforderungen werden zunächst vollständig erfasst Teile der Anforderungen werden inkrementell umgesetzt Definieren Ziel: Sicherstellen, dass inkrementelle Entwicklungen zu bisherigen Zwischenergebnissen passen Änderungen Vollständiges Produktmodell modifiz. Modell Definieren Änderungen If X=0 Nullversion X:=0 X:=X+1 Entwerfen Version X If X>0 Änderungen Änderungen partielle Architektur Implement. Version X Wünsche Produkt Version X Einsatz Version X 19
20 Definieren Kernsystem Das nebenläufige Modell partielles Modell Änderungen Definieren Ausbaustufe 1 Entwerfen Kernsystem partielle Architektur Änderungen erweitertes Modell Entwerfen Ausbaustufe 1 Änderungen Definieren Ausbaustufe 2 Erweitertes Produktmodell... Implement. Kernsystem Kernsystem erweiterte Architektur Implementieren Ausbaustufe 1 Änderungen Entwerfen Ausbaustufe 2 Erw. Produktarchitektur... erweitertes Kernsystem Implementieren Ausbaustufe 2 erweitertes Produkt... Produkt 20
21 Das Nebenläufiges Modell Parallelisierung des sequentiell organisierten Entwicklungsprozesses Förderung der Zusammenarbeit der einzelnen Personengruppen Dadurch Reduzierung unnötiger Korrekturen Erfahrungen der unterschiedlichen Personengruppen werden frühzeitig berücksichtigt Reduzierung von Wartezeiten und Zeitverzögerungen durch Parallelisierung Minimierung des Ausprobierens (Motto: right the first time : richtige Entscheidungen von Anfang an!) Reduzierung der Wartezeiten zwischen organisatorisch verbundenen Aktivitäten 21
22 Vorteile Das Nebenläufiges Modell: Bewertung Frühzeitige Erkennung und Lösung von Problemen Optimale Zeitausnutzung Nachteile Frühzeitige Entscheidungen können falsch sein Grundlegende und kritische Entscheidungen werden zu spät getroffen: Dadurch werden Iterationen notwendig Hoher Planungs- und Personalaufwand, um Fehler zu vermeiden bzw. zu antizipieren 22
23 Das Spiralmodell 23
24 Das Spiralmodell: Schritte (1) Schritt 1 Identifikation der Ziele des Teilprodukts (Leistung, Funktionalität,...) Ermittlung alternativer Realisierungsmöglichkeiten (Entwurf A, Entwurf B, Wiederverwendung, Kauf, etc.) Ermittlung der Randbedingungen für jede Alternative (Kosten, Zeit, Schnittstellen usw.) Schritt 2 Evaluierung der Alternativen unter Berücksichtigung der Ziele und Randbedingungen. Zeigt die Evaluierung, dass es Risiken gibt, dann ist eine kosteneffektive Strategie zu entwickeln, um die Risiken zu überwinden (Prototypen, Simulationen, Benutzerbefragungen, etc.) 24
25 Das Spiralmodell: Schritte (2) Schritt 3 In Abhängigkeit von den verbleibenden Risiken wird das Prozessmodell für diesen Schritt festgelegt (z.b. evolutionäres Modell, Prototypenmodell oder Wasserfallmodell) Kombination von verschiedenen Modellen ist möglich, wenn dadurch die Risiken minimiert werden Schritt 4 Planung des nächsten Zyklus einschließlich der benötigten Ressourcen Überprüfung (Review) der Schritte 1 bis 3 einschließlich der Planung für den nächsten Zyklus durch die betroffenen Personengruppen oder Organisationen. Einverständnis (Commitment) über den nächsten Zyklus herstellen 25
26 Meta-Modell Das Spiralmodell Risikogetriebenes Modell, oberstes Ziel: Risikominimierung Für jedes Teilprodukt und für jede Verfeinerungsebene sind die vier zyklischen Schritte zu durchlaufen Ziele eines Zyklus ergeben sich aus den Ergebnissen des letzten Zyklus Separate Spiralzyklen können für verschiedene Software- Komponenten durchgeführt werden Keine Trennung von Entwicklung und Wartung 26
27 Das Spiralmodell: Bewertung Vorteile Flexibles Modell Periodische, risikogetriebene Überprüfung und erneute Festlegung des Ablaufs Ein Prozessmodell wird nicht für die gesamte Entwicklung festgelegt, Integration anderer Prozessmodelle Fehler und ungeeignete Alternativen werden früh eliminiert Unterstützung der Wiederverwendung durch Betrachtung von Alternativen Nachteile Hoher Managementaufwand, da oft Entscheidungen über den Prozessablauf getroffen werden müssen Für kleine und mittlere Projekte ungeeignet Wissen über die Handhabung von Risiken nicht immer verfügbar 27
28 Zusammenfassung Prozess- Modell Primäres Ziel Antreibendes Moment Benutzerbeteiligung Charakteristika Wasserfall- Modell Dokumente gering sequentiell, volle Breite V-Modell minimaler Managementaufwand Prototypen- Modell maximale Qualität (safe-to-market) Dokumente gering sequentiell, volle Breite, Validation, Verifikation Risikominimierung Code hoch nur Teilsysteme Evolutionäres- Modell Inkrementelles Modell Nebenläufiges Modell minimale Entwicklungszeit (fast-to-market) minimale Entwicklungszeit Risikomimimierung minimale Entwicklungszeit Code mittel nur Kernsystem Code mittel volle Definition, dann zunächst nur Kernsystem Zeit hoch volle Breite, nebenläufig Spiralmodell Risikominimierung Risiko mittel Entscheidung pro Zyklus über weiteres Vorgehen 28
29 Einführung in UML UML (Unified Modeling Language) ist eine standardisierte Sprache und Notation zur Darstellung, Konstruktion, Dokumentation und Spezifikation von (objektorientierten) Modellen UML verwendet verschiedene Diagrammtypen zur Darstellung unterschiedlicher Aspekte eines Systems Statische Aspekte Dynamische Aspekte Benutzeranforderungen an das System Implementierungsbezogene Aspekte 29
30 Diagrammtypen in UML Modellierung der statischen Aspekte Klassen- und Objektdiagramme: Darstellung von Klassen, Objekten und deren statischen Beziehungen Modellierung der dynamischen Aspekte Verhaltensdiagramme: Beschreiben das Verhalten von Objekten des Systems Sequenzdiagramme: Darstellung von Nachrichtenfolgen zwischen Objekten einer oder mehrerer Klassen Kollaborationsdiagramme: Beschreiben das Zusammenwirken von Objekten beim Ausführen von Operationen Zustandsdiagramme: Darstellung der Zustände und Zustandsübergänge der Objekte einer Klasse Modellierung der funktionalen Anforderungen an das System Anwendungsfalldiagramme: Darstellung der Interaktionen zwischen externen Objekten (Akteuren) und dem System Modellierung implementierungsbezogener Aspekte (Komponentendiagramme, Einsatzdiagramme) 30
31 Klassendiagramme Klassenname Attributname: Typ Attributname: Typ=Initialwert [+ - #]Attributname: Typ=Initialwert Klassenattributname: Typ=Initialwert Operationsname Operationsname: Rückgabetyp Operationsname (Parameter: Typ): Rückgabetyp [+ - #] Operationsname (Parameter: Typ): Rückgabetyp Klassenoperation (Parameter: Typ): Rückgabetyp Klassenname Attribute Methoden Sichtbarkeit +: public #: protected -: private 31
32 Klassendiagramme: Beispiele (1) Klassen werden durch Rechtecke dargestellt Klassenname muss eindeutig sein Person Kunde Firma GeomObjekt Position_x : int Position_y : int verschieben(int, int) 32
33 Klassendiagramme: Beispiel Klassensymbol GeomObjekt Position_x : int Position_y : int verschieben(int, int) Java-Umsetzung public class GeomObjekt { int Position_x; int Position_y; public void verschieben (int dx, int dy) { Position_x = Position_x +dx; Position_y = Position_y +dy; } } Objektsymbol MeinGeomObjekt:GeomObjekt Position_x : 0 Position_y : 0 33
34 Klassendiagramme: Beziehungen Assoziation: Darstellung struktureller Beziehungen Aggregation: Darstellung hierarchischer Beziehungen Generalisierung und Spezialisierung 34
35 Klassendiagramme: Assoziationen Strukturelle Beziehungen zwischen Klassen werden durch Assoziationen dargestellt Binäre, n-äre und reflexive Assoziationen sind möglich Zusatzinformationen bei Assoziationen: Name der Assoziation: Beschreibt Art der Beziehung (Optional kann die Leserichtung angegeben werden) Rollen in der Assoziation: Beschreiben die Rollen der an der Assoziation beteiligten Klassen Kardinalität der Assoziation: Gibt an, mit wie vielen Objekten der gegenüberliegenden Klasse ein Objekt assoziiert sein kann Klasse 1 Klasse 1 Klasse 1 Klasse 1 Klasse 1 Klasse 1 Binäre Assoziation Reflexive Assoziation n-äre Assoziation (n=3) 35
36 Klassendiagramme: Assoziationen Mitarbeiter Name Adresse... Leserichtung * beschäftigt 1 Unternehmen Name Adresse... Katja: Person verheiratet mit Bernd: Person Rollenname Person Arbeitsnehmer Arbeitsgeber Unternehmen 36
37 Klassendiagramme: Aggregation Sonderform der Assoziation Dient zur Darstellung von Teil-ganzes-Beziehungen Unternehmen besteht aus Abteilung besteht aus Mitarbeiter 1 1..* 1 1..* Team besteht aus Teammitglied 1 1..n 37
38 Klassendiagramme: Generalisierung und Spezialisierung (1) Bei der Generalisierung und Spezialisierung werden Eigenschaften hierarchisch gegliedert, d.h allgemeine Eigenschaften werden Oberklassen und speziellere Eigenschaften Unterklassen zugeordnet Unterklassen verfügen über ihre speziellen Eigenschaften und erben die Eigenschaften ihrer Oberklassen Oberklasse Geschäftspartner Unterklase Kunde Lieferant 38
39 Klassendiagramme: Generalisierung und Spezialisierung (2) GeomObjekt Position_x : int Position_y : int Sichtbar: Boolean Anzeigen() verschieben(int, int): void Radius: int Kreis SetRadius(int) a : int b : int seta(neua) setb(neub) Rechteck a : int b : int C: int seta(neua) setb(neub) setc(neuc) Dreieck 39
40 Anwendungsfalldiagramme (1) Ein Anwendungsfalldiagramm besteht aus einer Menge von Anwendungsfällen und stellt Beziehungen zwischen Akteuren und Anwendungsfällen dar Anwendungsfälle beschreiben das für den Benutzer sichtbare Systemverhalten wie Akteure mit dem System interagieren Akteure repräsentieren Rollen (Konkrete Benutzer können gleichzeitig mehrere Rollen spielen) 40
41 UML-Notation Anwendungsfalldiagramme (2) Name Anwendungsfall Name oder <<actor>> Name Akteur <<actor>> Name Name Beziehung zwischen Anwendungsfall und Akteur: Der Akteur führt den Anwendungsfall aus. 41
42 Anwendungsfalldiagramme: Beispiel Auftrag annehmen <<actor>> Lieferant Auftrag ausliefern Bestellung tätigen <<actor>> Kunde Systemgrenze Auftrag abbrechen Lieferung akzeptieren 42
43 Literatur Balzert, H.: Lehrbuch der Software-Technik; Spektrum, Akad. Verl.; Heidelberg, 1996 Kahlbrandt, B.: Software-Engineering mit der Unified Modeling Language; Springer Verlag,
Softwaretechnik. 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
MehrSoftware Entwicklung 2. Prozessmodelle
Software Entwicklung 2 Prozessmodelle Inhalt Das Wasserfall-Modell Das V-Modell Das Prototypen-Modell Das evolutionäre/inkrementelle Modell Das nebenläufige Modell Überblick über die Prozessmodelle 2 Lernziele
MehrWirtschaftsinformatik I Teil 2. Sommersemester 2008. 1. Übung
Wirtschaftsinformatik I Teil 2 Sommersemester 2008 1. Übung Sarah Mund, Kirstin Simon, Markus Trierweiler, Christian Molitor, Jonathan Jäger, Björn Kirsten Aufgabenstellung Diskutieren Sie die Vor- und
MehrGrundlagen Software Engineering
1 Grundlagen Software Engineering Prozesse GSE: Prof. Dr. Liggesmeyer, 1 Organisation: Prozessmodelle Inhalt Das Wasserfall-Modell Das V-Modell Das evolutionäre/inkrementelle Modell Das nebenläufige Modell
MehrWas versteht man unter einem Softwareentwicklungsmodell?
Softwareentwicklung Was versteht man unter einem Softwareentwicklungsmodell? Ein Softwareentwicklungsmodell ist ein für die Softwareentwicklung angepasstes Vorgehensmodell bei der professionellen ( ingenieursmäßigen
MehrDer Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle
Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind
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)
Mehr4. Organisation: Prozess-Modelle
Software Management 4. Organisation: Prozess-Modelle 1 Übersicht der Vorlesung 1. 2. 3. 4. 5. 6. 7. 8. Grundlagen Planung Organisation: Gestaltung Organisation: Prozess-Modelle Personal Leitung Innovationsmanagement
MehrFachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer
Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Klassendiagramme Ein Klassendiagramm dient in der objektorientierten Softwareentwicklung zur Darstellung von Klassen und den Beziehungen,
MehrKlassendiagramm. (class diagram)
: Klassendiagramm http:///topic95.html Klassendiagramm (class diagram) Klassendiagramm Objektdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm Einstieg Paketdiagramm Aufbau
MehrSoftware-Lebenszyklus
Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung
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
MehrDas Wasserfallmodell - Überblick
Das Wasserfallmodell - Überblick Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Ziel: Verminderung
MehrProgrammiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny
Programmiersprache 2 (C++) Prof. Dr. Stefan Enderle NTA Isny 3. UML Klassendiagramm Nachtrag 3.1 Einführung UML UML ist eine standardisierte Sprache zur Modellierung von Systemen. In UML werden graphische
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
MehrKlassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla
BlaBla Diese Kennzeichnungen sind nur Erläuterungen und nicht Bestandteil des Diagramms Quelle: P.Grässle, H.Baumann, P.Baumann, UML projektorientiert, Galileo Verlag, 2003 21 Primäre Begriffe Kapselung
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
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
MehrProjektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung
Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/
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Ü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 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se
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
MehrWintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22
Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften
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
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?
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
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?
MehrIT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle
IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse
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
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
MehrÜbung Einführung in die Softwaretechnik
Lehrstuhl für Informatik 3 RWTH Aachen Übung Einführung in die Softwaretechnik Lösungshinweise zum Übungsblatt 3 Aufgabe 6a) Welche Projekttypen gibt es, und wie ist deren Zusammenhang? Systementwicklung
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,
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
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??
MehrTestplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013
Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael
MehrAgile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg
Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen
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
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
MehrQualitätsmanagement im Projekt
Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung
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
MehrEinführung und Motivation
Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.
MehrKlausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement
Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. Dr. H.-G. Gräbe, T. Riechert Institut für Informatik Sommersemester 2010 Allgemeine Bemerkungen Jedes Blatt ist mit
MehrTechniken der Projektentwicklungen
Von der Analyse zum Entwurf 5. Termin Vom Use Case zum Domänenmodell Bis zum nächsten Mal Vom Use Case zum Domänenmodell Vom Use Case zum Domänenmodell Was ist ein Domänenmodell? Graphische Beschreibung
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
MehrÄnderungsmanagement bei iterativer SW-Entwicklung
Änderungsmanagement bei iterativer SW-Entwicklung Vortrag auf der regionalen Fachgruppe IT-Projektmanagement, 05.05.2006, Stuttgart Dr. Karsten Hoffmann, Steinbeis-Transferzentrum IT-Projektmanagement,
MehrVorlesung Softwaretechnik - Vorgehensmodelle, V-Modell XT -
Vorlesung Softwaretechnik - Vorgehensmodelle, V-Modell XT - Prof. Dr.-Ing. Klaus-Peter Fähnrich WS 2007/2008 Prof. K.-P.Fähnrich 1 Übersicht Vorgehensmodelle Allgemein Vorgehensmodelltypen Das V-Modell
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
MehrSoftware Engineering
Software Engineering Prof. Adrian A. Müller, PMP Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern, Standort Zweibrücken Prof. A. Müller, FH KL Software Engineering Winter '12/'13
MehrLösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung
Prof. Dr. Dr. h.c. M. Broy Klausurlösung Dr. H. Ehler, S. Wagner 2. Juli 2004 Lösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung Aufgabe 1 Prozessmodelle (4
MehrSWE5 Übungen zu Software-Engineering
1 Übungen zu Software-Engineering 1) Klassen und Objekte 2) Telefonanlage 3) Objekt- und Klassendiagramme 4) Assoziationen 5) Telefonanlage (Erweiterung) 6) Fahrzeuge 7) Familien 2 Aufgabe 1: Klassen und
MehrProjektplan(ung) zu CYOUTOO
Seite 1 von 8 Projektplan(ung) zu CYOUTOO Inhalt Allgemeines 2 Die Meilensteine 3 Geplante Meilensteine des Projekts 3 Projektziel 1 4 Zielerläuterung 4 Meilensteine zu Projektziel 1. 4 Ergebnis 4 Projektziel
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
MehrZusammenfassung der Vorlesung
Zusammenfassung der Vorlesung Die wichtigsten Punkte der Vorlesung waren... Dr. F. Sarre Wintersemester Wintersemester 20102013 / 2011 / 2014 Folie 307 Herausforderungen beim Projektmanagement Projektziel
MehrTypisierung des Replikationsplan Wirries, Denis Datenbankspezialist
Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan
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
MehrInformationssystemanalyse Lebenszyklusmodelle 3 1. Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen:
Informationssystemanalyse Lebenszyklusmodelle 3 1 Aufgaben von Lebenszyklusmodellen Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen: Definition der Tätigkeiten im Entwicklungsprojekt Zusicherung
MehrKlausur 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):
MehrGPP Projekte gemeinsam zum Erfolg führen
GPP Projekte gemeinsam zum Erfolg führen IT-Sicherheit Schaffen Sie dauerhaft wirksame IT-Sicherheit nach zivilen oder militärischen Standards wie der ISO 27001, dem BSI Grundschutz oder der ZDv 54/100.
MehrCopyright 2014 Delta Software Technology GmbH. All Rights reserved.
Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für
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
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
MehrGrundlagen des Software Engineering
Grundlagen des Software Engineering Teil 1: SW-Management Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann Motivation des Risikomanagements Ungefähr 80 Prozent
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
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
MehrDie vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante
ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem
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
MehrVerhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {...
PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 31 Schlüsselwort: final Verhindert, dass eine Methode überschrieben wird public final int holekontostand() {... Erben von einer Klasse verbieten:
MehrSeite 1. Grundlagen Software Engineering. Organisation: Prozessmodelle. Prozessmodelle. Organisation. Inhalt
Grundlagen Software Engineering Prozesse GSE: Kritische Faktoren in der Softwareentwicklung Procedures and methods defining the relationship of tasks B A D C PROCESS People with skills, training, and Tools
MehrJava Einführung Umsetzung von Beziehungen zwischen Klassen. Kapitel 7
Java Einführung Umsetzung von Beziehungen zwischen Klassen Kapitel 7 Inhalt Wiederholung: Klassendiagramm in UML Java-Umsetzung von Generalisierung Komposition Assoziationen 2 Das Klassendiagramm Zweck
Mehr<thema> Projektdokumentation zum Softwareentwicklungsprojekt. (Entwicklerdokumentation) 28. Mai 2015
Projektdokumentation zum Softwareentwicklungsprojekt (Entwicklerdokumentation) Lehrveranstaltung Software Engineering I / II 28. Mai 2015 Entwickler: , , Auftraggeber:
Mehr6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]
1 Software-Qualitätssicherung 2 Integrationsstrategien big bang 6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] nicht-inkrementell geschäftsprozeßorientiert Prof. Dr. Helmut Balzert Lehrstuhl
MehrSoftware Engineering. 3. Analyse und Anforderungsmanagement
Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz
MehrNeues Modul für individuelle Anlagen. Änderung bei den Postleitzahl-Mutationen
NEWSLETTER APRIL 2015 Neues Modul für individuelle Anlagen Die LESS Informatik hat in Zusammenarbeit mit einem Kunden die Umsetzung des neuen Moduls 1e für die Anwendung von individuelle Anlagen in Angriff
MehrRobot Karol für Delphi
Robot Karol für Delphi Reinhard Nitzsche, OSZ Handel I Version 0.1 vom 24. Januar 2003 Zusammenfassung Nach der Einführung in die (variablenfreie) Programmierung mit Robot Karol von Freiberger und Krško
Mehr6. Programmentwicklung
6. Programmentwicklung Fertigungsprozess Qualitativ hochwertige Software ist ein Industrieprodukt -> Methoden der Industrie übertragen auf der Herstellprozess -> Herstellprozess gliedert sich in Phasen
MehrSEP 114. Design by Contract
Design by Contract SEP 114 Design by Contract Teile das zu entwickelnde Programm in kleine Einheiten (Klassen, Methoden), die unabhängig voneinander entwickelt und überprüft werden können. Einheiten mit
MehrModul 07-203-2102. Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement
Modul 07-203-2102 Klausur zu den Teilgebieten Software-Management und Software-Qualitätsmanagement Prof. Fähnrich, Prof. Gräbe, Dr. Riechert Institut für Informatik Sommersemester 2013 Allgemeine Bemerkungen
Mehr13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES
13 Anhang A: Erfüllung der Norm ISO 9000 durch Hinweis Einleitung Eine der wesentlichsten Grundlagen für die Qualitätssicherung in einem Unternehmen ist die Normenserie «ISO 9000», insbesondere ISO 9001:1994
MehrTraceability-Modell als Erfolgsfaktor für Process Enactment. Paul-Roux Wentzel, SEE 2008
Traceability-Modell als Erfolgsfaktor für Process Enactment Einführung Referent Paul-Roux Wentzel Unternehmen method park Software AG 2008 method park Software AG Slide 2 Leistungsportfolio Training &
MehrEntwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...
Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...
MehrRequirements Engineering I. Der Spezifikationsprozess!
Norbert Seyff Requirements Engineering I Zusammenfassung und Erweiterung Der Spezifikationsprozess! 2009, 2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den
MehrDie Softwareentwicklungsphasen!
Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.
Mehr4. AuD Tafelübung T-C3
4. AuD Tafelübung T-C3 Simon Ruderich 17. November 2010 Arrays Unregelmäßige Arrays i n t [ ] [ ] x = new i n t [ 3 ] [ 4 ] ; x [ 2 ] = new i n t [ 2 ] ; for ( i n t i = 0; i < x. l e n g t h ; i ++) {
MehrSystemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 -
Systemanalyse - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 4 - Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule
MehrPrüfung Software Engineering I (IB)
Hochschule für angewandte Wissenschaften München Fakultät für Informatik und Mathematik Studiengruppe IB 3 A Wintersemester 2014/15 Prüfung Software Engineering I (IB) Datum : 21.01.2015, 14:30 Uhr Bearbeitungszeit
MehrSoftwareentwicklungsprozess im Praktikum. 23. April 2015
Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit
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
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
MehrKlassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java
Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte
MehrSoftware Systems Engineering
Software : SoSe 08 Prof. Dr. Klaus Schmid Software Produktlinien Ein neues Programm soll erstellt werden. Das habe ich doch schon mal programmiert, oder? Alter Code passt aber nicht ganz! Wird passend
Mehr2. Tutorium zu Softwaretechnik I
2. Tutorium zu Softwaretechnik I Lastenheft, Durchführbarkeitsuntersuchung und Klassendiagramme Michael Hoff 06.05.2014 INSTITUT FÜR PROGRAMMSTRUKTUREN UND DATENORGANISATION KIT Universität des Landes
MehrSoftware Maintenance - Musterlösung zum Übungsblatt 1
Software Maintenance - Musterlösung zum Übungsblatt 1 Beispiel 1) Kosten für 12 Monate: Kosten altes Produkt: 1000 * 12 = 12000 Kosten Neuentwicklung: 1000 Wartung des alten Produktes während der Entwicklung
MehrIKP Uni Bonn Medienpraxis EDV II Internet Projekt
IKP Uni Bonn Medienpraxis EDV II Internet Projekt WS 2001/2002 Dozentin: Lucie Prinz Grundlagen der Projektarbeit Was ist ein Projekt? Die Phasen eines Software Projektes Die Projektunterlagen Die Projektplanung
MehrWhitebox-Tests: Allgemeines
-Tests: Allgemeines Andere Bezeichnungen Logic driven, Strukturelles Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation Intuitiv
MehrInhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...
Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...
MehrT1 - Fundamentaler Testprozess
AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In
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
Mehr3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.
1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes
Mehr