Softwareengineering & Projektmanagement Zusammenfassung

Größe: px
Ab Seite anzeigen:

Download "Softwareengineering & Projektmanagement Zusammenfassung"

Transkript

1 Softwareengineering & Projektmanagement Zusammenfassung Block 1-1 Einführung Begriffsdefinitionen Software: Beinhaltet alle Instruktionen die dem Computer vorschreiben, was er zu tun hat. Programme, die die Hardware des Computers kontrollieren. Software Engineering: Vorgehensweise zur systematischen Erstellung von Software nach ingenieurmäßigen Prinzipien. Analyse: Erfassen und Verarbeiten von Anforderungen (Pflichtenheft). Design: Entwurf der internen Struktur des Systems (Systemarchitektur). Validierung: Überprüfung des Verhaltens eines Programms durch festgesetzte Testfälle (gemäß den Anforderungen). Capability Maturity Model Integrated (CMMI) Reifegrade für Prozesse. Block 1-2 Projekttypen Unterscheidungsmerkmale Merkmal Messbare Attribute Beispiel Größe Anzahl der beteiligten Personen Personen: 50 Dauer Anzahl Tage bzw. Wochen Dauer: 52 Wochen Personen-Jahre: PY Verwendete Technologien Art, Anzahl, Alter der Technologien Art: Scriping language, Alter: 4 J., Anzahl: 5 Komplexität Anzahl Klassen, Module, Datenbanken; verwendete Technologien, Codezeilen Datenbanken: 2 Klassen: 42 mit Zeilen Seite 1

2 Block 1-2 Projekttypen (Fortsetzung) Softwarebeschaffung Entspricht den Anforderungen Änderbarkeit Preis Kauf Abänderung Neuerstellung Ungefähr (oft viele Oft ist keine exakte Genau ungenützte Funktionen Anpassung möglich oder ein paar fehlende) Beschränkung durch Schwierig, da technische Details oft nicht transparent sind Nach Anforderung + Verbreitung Beispiele für Softwareprojekte technische Grenzen Ausgangsprodukt wurde selbst hergestellt: leicht änderbar, Durch andere hergestellt: Schwer änderbar - durch eigene IT- Abteilung: kalkulierbar - durch andere: kostenintensiver Gut möglich (Dokumentation der Entwicklung und somit techn. Transparenz vorhanden) Teuer Kommerzielle Systeme (Benutzergesteuert, Zuverlässigkeit oft nicht entscheidend, ), eingebettete Systeme/Echtzeitsysteme (Ereignisgesteuert, oft auch vollständig automatisiert; Zuverlässigkeit sehr wichtig, ), Webapplikationen, Computerspiele, Unterschiedlicher Fokus auf Benutzerschnittstelle, Anwendung und Betriebssystem Top Ten der Gründe, warum Projekte scheitern 1. Unvollständige Anforderungen 2. Anwender nicht involviert 3. Zu wenig Ressourcen 4. Unrealistische Zeit- und Kostenpläne 5. Keine Management Unterstützung 6. Häufige Änderung der Anforderungen 7. Qualitätsmängel bei extern vergebenen Komponenten 8. Qualitätsmängel bei extern vergebenen Aufgaben 9. Fehlende Planung 10. Projekt wird nicht mehr benötigt Faktoren für ein erfolgreiches Projekt 1. Einbringung und Berücksichtigung der Anwender 2. Adäquates Projektmanagement: nicht zu viel aber auch nicht zu wenig 3. Anforderungen müssen eindeutig beschrieben, realisierbar und auch überprüfbar sein 4. Flexibler, realistischer Projektplan, der mögl. Verzögerungen berücksichtigt 5. Realistische Kostenschätzung und Budget, inkl. Risikoanalyse 6. Angemessene Ziele 7. Schlüsselteammitglieder haben genügend Projekterfahrung 8. Gute Teamarbeit, funktionierende Kommunikation im Team Zusammenfassung Verschiedene Anforderungen erfordern verschiedene Lösungsansätze Mit der Projektgröße ändern sich viele Faktoren des Projekts - Komplexität, Bedarf an Planung, Organisation etc. Die Eigenentwicklung von Software ist nicht immer die beste Lösung Unterschiede eingebettete Systeme vs. kommerzielle Software Seite 2

3 Block 1-3 Softwareprozesse und Produkte Produktqualitäten Anforderungen - stabil und ausreichend genau beschrieben, übersichtliche Darstellung - Systembeschreibung, Anwendungsfälle, Nichtfunktionale Anforderungen Design - Skalierbarkeit, Performance, Erweiterbarkeit - Übereinstimmung mit Anforderungen, ausreichend dokumentiert Testplan - Testrahmen, Teststrategie, Testfälle, Testzeitplan - Nachvollziehbare Beschreibung, Anforderungen vollständig abgedeckt Testbericht - Version des Systems und der DB, Testfälle mit unerwartetem Ergebnis - verwendete Eingabedaten, welche Korrekturen sind nötig Benutzerschnittstelle - Usability für Zielgruppen, Überprüfung mit Prototyp - Dialoge nicht überladen, einheitliches Layout, Fehlermeldungen einheitlich Datenbank - Redundanzfrei, Wachstum der Datenbestände berücksichtigen - Übereinstimmung mit Klassenmodellen, Integritätsbedingungen Technische Dokumentation - Verständlich, korrekt, vollständig, Format und Stil ansprechend - Lehrbuchteil, Nachschlageteil, Stichworte/Glossar, Online-Hilfe Projektplan - Alle Tätigkeiten mit Verantwortlichen und Mitarbeitern - Realistische Angaben für Aufwand, geeignete Darstellung Prozessmodelle im Überblick Modell Phasen Eigenschaften Wasserfallmodell V-Modell Inkrementelles Modell Iteratives Modell (z.b. Unified Prozess) Extreme Programmierung Zusammenfassung Anforderungen, Spezifizierung, Planung, Design, Implementierung, Integration (jeweils mit Verifizierung) Voruntersuchung, Analyse, Design, Implementierung, Test, Integration Analyse, Entwurf, Implementierung Integration, Auslieferung an Kunden Etablierung, Entwurf, Konstruktion, Übergang Coding, Testing, Listening, Designing laufen dauern parallel ab und nicht in Phasen Umsetzung des Life Cycles, sehr einfach, Risikominimierung durch Phasenabschlüsse, starke Auswirkung von Fehlern, keine parallele Entwicklung, Anforderungen wichtig Einfache Kontrolle des Projektfortschritts, für große Projekte mit Qualitätsanspruch Stufenweise Entwicklung, für große komplexe Systeme mit langer Entwicklungszeit bei jeder Iteration wird mehr Funktionalität realisiert, Granulare Abstufung Projekte mit schnell wechselnden oder vagen Anforderungen, mit kleinen Entwicklergruppen, zeitkritische Projekte Unterschiedliche Projekttypen erfordern die Wahl des richtigen Vorgehensmodells Produkte haben mehrere Qualitäten, die zu beachten sind Im gesamten Projekt müssen die Anforderungen immer gegenwärtig bleiben, d.h. es muss überprüft werden, ob die gewünschten Anforderungen erfüllt werden und geänderte Anforderungen müssen berücksichtigt werden. Seite 3

4 Block 2 Projektmanagement (Teil 1) Begriffsdefinition Projekt Zeitlich begrenztes, einmaliges Vorhaben Beschränkte Ressourcen Klar definierte Ziele Ein Projekt ist ein einmaliges Vorhaben mit einem definierbaren Anfang, einem definierbaren Ende und mehrere Personen sind daran beteiligt. Erfordert oft interdisziplinäre Zusammenarbeit Kein Tagesgeschäft/Permanentes Vorhaben Keine Maßnahme/Temporäres Vorhabe Besitzt in der Regel definierte Kriterien (Dauer, Budget, Risiko, Komplexität, Innovationsgrad, ) - MUSS-Kriterien sind entscheidend ob Projektmanagement notwendig ist oder nicht! - KANN-Kriterien bestimmen Umfang beziehungsweise Aufwand für das Projektmanagement Begriffsdefinition Projektmanagement Projektmanagement ist eine Gesamtheit von Methoden und Verhaltensweisen zur effizienteren Steuerung und Abwicklung von besonderen Aufgabenstellungen (Projekten). Bei der effizienten Steuerung geht es grundsätzlich immer um Projektmanagement im engeren Sinn = Projektleitung (für die Führung/Steuerung eines Projektes verantwortliche Person/Stelle) Projektmanagement im weiteren Sinn = Gesamtheit der Peronen/Stellen, die mit der Führung/Steuerung eines Projektes befasst sind Elemente des Projektmanagements Projektablauf was ist zu tun? (Start, Verfolgung, Abschluss) Arbeitsstruktur wer ist wofür zuständig? Informationswesen wer informiert wen, worüber, wann, wie? Dabei müssen die notwendige Methodenunterstützung, psychologische Aspekte sowie Umfeldbedingungen beachtet werden Seite 4

5 Block 2 Projektmanagement (Teil 1) (Fortsetzung) Projektstart Projektstart = Der Abschnitt von der Projektidee bis zum Kick off Projektinitiative (Idee, Design der Verantwortlichkeiten, Organisieren der Planung) Es muss entschieden werden a) ob ein Projektmanagement überhaupt notwendig ist. b) ob es sich überhaupt um ein Projekt handelt (existieren Muss-Kriterien?). c) in welcher Form das Projekt stattfinden soll. d) wann und wie die ersten Planungsgespräche stattfinden sollen. Vorarbeiten (Evaluierung der Projektidee, eventuell Erstellung einer Vorstudie, Ersteinschätzung der Ressourcenanforderungen) sind notwendig a) um zu entscheiden, ob ein Projekt überhaupt in Angriff genommen werden soll. b) zur Konkretisierung einzelner Punkte des Projekt c) um das Projektrisiko zu minimieren. Projektbeauftragung (Konkretisierung von Leistungen, Termine, Budget und Ressourceneinsatz im Rahmen von Planungsbesprechungen; Ausarbeitung eines Projektauftrags; Ausverhandlung des Projektauftrags mit Auftraggeber) Der Projektauftrag ist eine schriftliche (Ziel-)Vereinbarung zwischen Auftraggeber und Auftragnehmer, ein Projekt zu bestimmten Bedingungen durchzuführen. Er wird auch Projektantrag, Projekterklärung, Projektdefinition und Projektbeschreibung genannt und ist eine Management-Unterlage, d.h. er umfasst alle wichtigen Daten für die zukünftige Projektabwicklung. Kick-off (Freigabe durch den Auftraggeber, Startarbeiten, Einleitung der Projektverfolgung) Block 4 Software Engineering Phasen Software Life-Cycle Abfolge von Schritten (Phasen) mit qualitätsverbessernden Maßnahmen Basiskonzept für Prozesse und Vorgehensmodelle Seite 5

6 Block 4 Software Engineering Phasen (Fortsetzung) Software Life-Cycle Phasenbeschreibung Anforderungen zeigen die Wünsche des Kunden in Bezug auf das Softwareprodukt. (user/customer view) Anforderungen müssen testbar sein und getestet werden! Eine Spezifikation beschreibt das System aus technischer Sicht (engineering view). Planung: Erstellung des Projektplans: Zeit, Dauer, und Kosten (project management). Entwurf / Design: technische Lösung der Systemanforderungen (Komponenten, Packages, Datenbankdesign). Implementierung und Testen: Erzeugung des Softwareprodukts. Integration und Testen: Zusammenfügen und Test der einzelnen Komponenten auf Architektur- und Systemebene. Operation und Wartung: Fehlerbehebung, Unterstützung, Erweiterungen des Softwareproduktes während des laufenden Betriebes. Retirement: Nach der Einsatzphase, d.h. am Ende des Produktlebenszyklus, muss das Softwareprodukt kontrolliert aus dem Betrieb genommen werden. Begriffsdefinition Anforderungen Durch Anforderungen wird ein gemeinsames Verständnis hergestellt, was das Produkt können soll, und sie drücken das gewünschte Verhalten aus Nutzersicht aus. Berücksichtigung unterschiedlicher Stakeholders (Kunde/Anwender, Entwickler, usw.) Anforderungen müssen testbar und nachvollziehbar sein! Anforderungen werden validiert! (Entwickeln wir das richtige Produkt?) Viele Hauptgründe für Projektfehlschläge lassen sich auf Anforderungen zurückführen. Anforderungen an die Anforderungen: Gültigkeit, Konsistenz, Vollständigkeit, Realismus, Überprüfbarkeit, Verständlichkeit, Verfolgbarkeit, Anpassbarkeit Vier Richtlininien - Value-driven requirements Erfordert Geschäftsfall-Analyse - Shared-vision driven requirements Stakeholder bewerten regelmäßig die Anforderungen Gesamtheitliche Sicht ist wichtiger als präzise Anforderungen Arten von Anforderungen - Change-driven requirements Die Erweiterbarkeit und Anpassung wird oft vernachlässigt - Risk-driven requirements Wie detailliert müssen Anforderungen sein? If it s risky to leave it out, put it in Funktionale Anforderungen (z.b. Use-Cases) - Was beziehungsweise welche Funktionen sollen umgesetzt werden? - Wie soll sich das System in definierten Situationen verhalten? Nicht-funktionale Anforderungen (z.b. Qualitätskriterien) - Welche sonstigen Anforderungen müssen umgesetzt werden, die nicht direkt auf die Funktionalität abzielen, sie aber beeinflussen, z.b. Leistung und Performance (z.b. Optimierung des Informationsflusses). Usability und menschliche Faktoren (z.b. Einfachheit der Bedienung, Training). Sicherheit (z.b. Zugangskontrolle), Wartbarkeit (Trennung von Anwendung und Daten), Erweiterbarkeit. Designbedingungen - Worauf soll beim technischen Entwurf geachtet werden, z.b. Schnittstellen, Plattformen und Entwicklungsumgebung, verteilte Entwicklung. Prozessbedingungen - Rahmenbedingungen im Softwareprojekt, z.b. Ressourcen, Dokumentation. Seite 6

7 Block 4 Software Engineering Phasen (Fortsetzung) Priorisierung von Anforderungen Hauptanforderungen (must-be Kritieren). Gewünschte Anforderungen (expected, nicht entscheidend aber wichtig). Optionale Anforderungen (nice-to-have Kriterien). Entwurf und Design Beinhalten Architekturdefinitionen, Schnittstellendefinitionen, Domänen- und Datenbankmodelle, Komponentendefinitionen, User Interfaces, technische Anwendungsfälle (mit Anforderungen an Subsysteme und Lösungsweg) In der Regel in der Sprache der Techniker verfasst. Das Designdokument ist Grundlage der Implementierung! Wesentliche Komponenten: Software Architectural Design & Software Detailed Design 4+1 View Model of Architecture Teilaspekte der Architektur und des Designs und die spezifischen Eigenschaften eines Systems über verschiedene Sichten (views) beschrieben. Stammt aus der UML-Familie. Logical View Funktionale Anforderungen. Fokus auf den End-User. Beispiele: Design Packages, Subsysteme, Klassen. UML 2: Klassendiagramme, State-Machines, Package Diagrams usw. Process View Nicht-funktionale Anforderungen. Fokus auf Systemintegration. Beispiele: Laufzeitbedingungen, wie Concurrency, Lastverteilung, Fehlertoleranz. UML 2: Sequence, Activity Diagrams, Communication Diagrams. Implementation View Beschreibt statische Softwarekomponenten. Fokus auf Implementierung. Beispiele: Configuration Management, Source Code UML 2: Component Diagram der vorhandenen Softwareteile. Deployment View Ausführbare Applikationen (zur Laufzeit) unter Berücksichtigung der Plattform. Fokus auf Software Engineers. Beispiele: Deployment, Installation, Performance. UML 2: Deployment Diagrams. Seite 7

8 Block 4 Software Engineering Phasen (Fortsetzung) Use Case View Als Ergänzung zu den bisherigen Views, bildet der Use Case View den gemeinsamen Nenner, in dem die Anwendungsfälle und die Aktivitäten (als Szenarien) abgebildet und in einen Zusammenhang gesetzt werden. Fokus auf Systemanalyse sowie Entwurf und Design. - Der Use Case View bildet die Schnittstellenfunktion zwischen den anderen Sichten aus der Architektursicht - und beinhaltet Schlüsselszenarien (key scenarios) der Applikation aus der Sicht der Geschäftsprozesse. Fokus auf Implementierung und Transition - Verifikation und Validierung der Anforderungen (Test) und der vier Architektur-Views. UML 2: Use Case Diagram + Beschreibung, Aktivitätsdiagramme. Design Principles System Control (Wer übernimmt die Kontrolle im System?) Stair - Verteilte Kontrolle. - Schrittweise Ausführung von Funktionen, dadurch wechselt die Kontrolle. - Verbesserung der Wiederverwendbarkeit der Methoden (z.b. durch Vererbung). - Die spätere Wartung wird erschwert. Fork - Ein zentrales Objekt kontrolliert den gesamten Use Case. - Wiederverwendung von Datenobjekten (ohne Business Logik) wird erleichtert. - Wartbarkeit wird verbessert, da nur ein Objekt geändert werden muss. Abstraction Concept (z.b. Klasse) vs. Value (z.b. Objekt): Reduktion der Komplexität durch ignorieren von Details; z.b. Generalisierung in UML Klassendiagrammen. Decomposition und Modularisierung Aufteilung großer Systeme in mehrere kleinere unabhängige Teile (Komponentenorientierung). Trennung von funktionalen Anforderungen. Verbesserte Wiederverwendbarkeit. Encapsulation / Information Hiding Packaging von Instanzvariablen und Methoden in eine Klasse um die Komplexität des Objekts und der Implementierung zu reduzieren. z.b. private variables <> public properties. Trennung von Interface und Implementierung (z.b. durch Public und Private Interfaces) Die Implementierung einer Komponente kann geändert werden, solange das Interface unverändert bleibt. Seite 8

9 Block 4 Software Engineering Phasen (Fortsetzung) Standardisierung der Implementierung im Projekt Durch Implementierung einer ausreichenden und einheitlichen Dokumentation, zum Beispiel: Namenskonventionen zur Verbesserung der Lesbarkeit des Codes, z.b. gleiche Notation von Variablen, Methoden und Klassen. Formatierungsrichtlinien z.b. Einrückungen, gleicher Methoden und Komponentenaufbau erleichtern das Zurechtfinden in fremdem Code. Versionierungen ermöglichen einen raschen Überblick aller (Teil-)Produkte innerhalb eines Projektes und die Verwendung der letztgültigen Versionen (z.b. CVS, Dokumenttagebücher). Verwendung eines Headerblocks in jeder Komponente. Interne Standards (auf Unternehmensebene) zur Koordination der Teamaktivitäten, um Komplexität zu reduzieren und Lesbarkeit und Verständnis der Doukumente und des Source Codes zu gewährleisten versus übergereifende Standards Kommunikationsmethoden (z.b. Format und Inhalt der Nachrichten), Programmiersprachen (z.b. Syntax in Java), Plattformen (z.b. Interfaces zu Betriebssystemaufrufen), Tools (z.b. Notationen wie UML). Standardisierung durch Traceability Traceability ist die Nach- oder Rückverfolgbarkeit einer Information durch ihren gesamten Entwicklungszyklus (z.b. bei sicherheitskritischen Anwendungen gefordert). Änderungsverfolgung = die Fähigkeit, den Lebenszyklus einer Anforderung vom Ursprung der Anforderung über die verschiedenen Verfeinerungs- und Spezifikationsschritte bis hin zur Berücksichtigung der Anforderung in nachgelagerten Entwicklungsartefakten verfolgen zu können. Typische Fragestellungen: Woher kommt eine Anforderung und wo wurde sie umgesetzt? Welche Artefakte sind von einer Änderung der Anforderung betroffen? Welche Anforderungen sind von einer Änderung der Umsetzung betroffen? Arten der Traceability Seite 9

10 Block 4 Software Engineering Phasen (Fortsetzung) Systemintegration Durch Modularisierung (erleichtert Lesbar-, Wartbar- & Verständlichkeit der Softwarekomponenten) entstehen (komplexe) Systeme mit meist vielen unterschiedlichen getesteten Komponenten. Systemintegration bezeichnet die Integration unterschiedlicher Komponenten zu größeren (Sub-)Systemen. Dies geschieht auf unterschiedliche Art (je nach Komplexität und Systemtyp): Big-Bang Integration (für kleine, überschaubare Projekte) Gleichzeitige Integration aller Komponenten. - Vorteil: Da alle Komponenten verfügbar, kein zusätzlicher Testaufwand für Test-Stubs - Nachteile: Fehler sind schwer zu lokalisieren (z.b. Seiteneffekte), hohes Risiko Top-Down / Bottom-Up Integration Integration ausgewählter Komponenten mit eingeschränkter Gesamt-Funktionalität. - Top-Down Integration (Schrittweise Integration, ausgehend von den Geschäftsfällen) o Vorteil: ausführbares Produktframework früh verfügbar ( Prototypen, für Testfälle) o Nachteile: Zusätzlicher Aufwand für Test-Stubs, späte Integration (zusätzliches Risiko) - Bottom-Up Integration (Schrittweise Integration, beginnend bei der Hardware) o Vorteil: Stabiles System (basierend auf Hardwareinterfaces) o Nachteile: Ausführbares Gesamtsystem spät verfügbar, zusätzlicher Aufwand Build Integration Schrittweise Integration entsprechend den Business Cases (über unter-schiedliche Layer hinweg; z.b. über priorisierte Liste von Use-Cases). Phasen-orientierte Integration. - Vorteile: Frühe Verfügbarkeit von funktionalen Anforderungen (über alle Layer), also Prototypen, Berücksichtigung priorisierter Anforderungen möglich. - Nachteil: Komponentenwiederverwendung schwierig, Regressions-Tests erforderlich. Wartungsprozesse im Software Life-Cycle (Wartung Evolution Retirement) Beginnend mit der Inbetriebnahme, beginnt die Wartung (korrektiv, adaptiv und verbessernd) und endet mit der kontrollierten Außerbetriebnahme beziehungsweise Ersetzung durch anderes System. Wartungsprozesse beinhalten dieselben Phasen wie der Life-Cycle Prozess; einen speziellen Stellenwert nehmen die Anforderungsänderungen ein. Unterschiedliche Sichten auf die Wartung: Activity-View: Änderung des Software Systems nach Auslieferung (Delivery) und Inbetriebnahme (Deployment bzw. Product Launch). Process-View: Schritte zur Durchführung einer Wartungsaufgabe. Phase-Oriented-View: Die Wartungsphase beginnt mit der Auslieferung und Inbetriebnahme und Ende mit Stilllegung des Softwareproduktes. Wartungskategorien Correction Enhancement Proactive Preventive Perfective Reactive Corrective Adaptive Vorbeugende Wartung (Preventive) Verbesserung im Hinblick auf zukünftige Wartung (z.b. Ergänzung der Dokumentation). Korrektive Wartung (Korrektive) Bug- und Fehlerkorrektur (patches, workarounds, updates). Produktpflege und Verbesserung (Perfektive) Produktverbesserung (Erweiterungen, Verbesserung der Effizienz). Adaptive Wartungsaktivitäten (Adaptive) Berücksichtigung geänderter externer Anforderungen (Hardware, Softwareänderungen). Seite 10

11 Block 4 Software Engineering Phasen (Fortsetzung) Techniken zur Wartung Herstellen des Produktverständnisses (fremden Code lesen & verstehen, sehr zeitaufwändig, nur bei guter Dokumentation möglich, Key Tool: Code Browser) Reengineering (Überprüfen & Überarbeiten des Codes, gravierend und teuer) Reverse Engineering (Analyse der Software auf Komponenten und Zusammenhänge Modelle basierend auf dem Code auf höheren Abstraktionsniveau (z.b. Code zu UML) Phase Retirement Retirement = Am Ende der Betriebsphase (Betrieb und Wartung) kontrolliertes Stilllegen des Produktes beziehungsweise störungsfreier Übergang zu einem Nachfolgeprodukt. Zusammenfassung Der Life-Cycle Prozess umfasst sämtliche Schritte der Softwareentwicklung von der Konzeptphase bis zur Stilllegung des Softwareprodukts. Die Anforderungserhebung ist kritisch für den Erfolg eines Softwareproduktes. Änderungen oder Fehler wirken sich gravierend in späteren Phasen der Entwicklung aus. Entwurf und Design sind die Basis für die eigentliche Implementierung und legen den Aufbau des Systems fest. Designprinzipien sind zu beachten. Die Implementierung umfasst die Umsetzung der Anforderungen und des Entwurfs. Standards und Dokumentation unterstützen Softwareentwicklungsteams nicht nur bei der Erstellung sondern auch bei der Weiterentwicklung und Wartung. Qualitätssicherung und Testen sin ein integraler Bestandteil während des gesamten Projekt- Lebenszyklus. Sie dürfen nicht als Add-on gesehen werden. Ein Großteil der Wartung umfasst Erweiterungen des Produktes, aber auch Fehlerkorrektur und Anpassungen an geänderte Systemgegebenheiten. Die Retirement-Phase schließt den Software Life-Cycle ab, in dem das Softwareprodukt kontrolliert außer Betrieb genommen beziehungsweise ersetzt wird. Block 6 Modellierung von Anwendungsszenarien Modellierungssprachen Software-Entwicklung erfordert die Herstellung konsistenter Sichten auf Anforderungen und Entwurf eines Systems Modelle Prinzipien der Abstraktion; Information Hiding und Vererbung. Betrachtung des Wesentlichen (Brille) mit Hilfe von Richtlinien (Werkzeugkasten). Umgesetzt in Modellierungs- (mit Codegenerierung) oder Zeichenwerkzeugen (Diagramme) Modell versus Diagramm Ein UML-Modell ist eine Menge von Modellelementen (Klassen, Attribute, Anwendungsfälle). Ein UML-Diagramm ist eine Sicht auf ein Modell (Anwendungsfall-, Klassendiagramm). Elemente in unterschiedlichen Diagrammen können sich auf dasselbe Modell beziehen. Schemata für statische Aspekte UML ( immer ) Anwendungsfälle (Benutzer und Nützlichkeit definiert durch Akteure und Hauptszenarien) Klassen (Menge gleichartiger Objekte mit Attribute udgl., auch Datenbankschemata) Schemata für dynamische Aspekte mit UML ( wenn dann ) Sequenz (ge- und verbotene Interaktionsstrategien, Folgen von Nachrichten) Aktivität (proaktives Verhalten, Datenfluss zwischen Prozess- & Kontrollabläufen) Zustandsautomat (reaktives Verhalten, Zustände und Übergänge/Transitionen wichtig) Seite 11

12 Block 6 Modellierung von Anwendungsszenarien (Fortsetzung) Prozess und Datenfluss Analyse (IDEFØ) Modelliert Daten- und Kontrollfluss beziehungsweise Daten- und Kontrolltoken Aktivitätsdiagramm Zustandsdiagramm Und-Verfeinerung Oder-Verfeinerung Block 7 Ausgewählte Softwareprozesse Traditionelle Ansätze Wasserfallmodell (kleine Entwicklerteams), V-Modell Konzept (Spezifikationsphase versus Realisierung & Testen, große Projekte im öffentlichen Bereich, Doku und Anforderungen!) V-Modell XT (Verpflichtendes Vorgehensmodell für IT Projekte im öffentlichen Bereich in Deutschland, Vorgehensbausteine kapseln Rollen, Produkte [Mittelpunkt] und Aktivitäten) - Projekttypen werden eingeteilt nach Projektgegenstand und Projektrollen Vier Projekttypen o Systementwicklungsprojekt des Auftraggebers. o Systementwicklungsprojekt des Auftragnehmers. o Einführung und Pflege eines organisationsspezifischen Vorgehensmodells. o Systementwicklungsprojekt (Auftraggeber/Auftragnehmer). - Vorgehensbausteine untergliedert in V-Modell Kern (verpflichtende Elemente für alle Projekttypen), Einführung und Pflege, Elemente für die Systementwicklung, Auftraggeber / Auftragnehmer Schnittstelle. Seite 12

13 Block 7 Ausgewählte Softwareprozesse (Fortsetzung) Rational Unified Process (RUP) - Inkrementelle und iterative Vorgehensweise. Mehrere Iterationen pro Phase. - Vier grundlegende Phasen: Inception (Beginn), Elaboration (Entwurf & Design), Construction (Implementierung), Transition (Auslieferung) - Definierte Workflows und Disziplinen: sechs Engineering Workflows, drei Supporting Workflows - Vorteile: Werkzeugunterstützung, Vordefinierte Liste mit erforderlichen Artefakten. - Nachteile: Hohe Komplexität, hoher Dokumentationsaufwand. - Anwendungsbereich: Große Projekte durch eine ganzheitliche Prozess-Sicht auf das gesamte Projekt (inkl. Deployment). Ein Agiler Ansatz: SCRUM Agil bedeutet aber nicht unkontrolliert auch hier existieren Prozesse und Regeln, die eingehalten werden müssen. 12 Prinzipien, die die Basis für agile Entwicklung darstellen. Flexibles Prozessmodell, um auf ändernde Anforderungen im Projektablauf reagieren zu können. SCRUM ist keine Abkürzung; der Begriff stammt aus der Rugby Start-Formation. Der Sprint ist das zentrale Element. Seite 13

14 Block 7 Ausgewählte Softwareprozesse (Fortsetzung) SCRUM-Begriffsdefinitionen Backlog: Beinhaltet alle Arbeitspakete, die in nächster Zeit umgesetzt werden müssen (sowohl klar definierte als auch vage Anforderungen): Produkt vs. Sprint Backlog (priorisierte Gesamtliste versus Features, die in einem einzelnen Sprint umgesetzt werden aufgespalten in Tasks ). Daily-Scrum: Eine tägliche Projektbesprechung um etwaige Fragen / Missverständnisse zu klären; Definition des täglichen Arbeitsauftrags. Scrum Team: Funktionsübergreifendes Team, zuständig für den Sprint Backlog. Burndown Chart: Visuelle Darstellung des Projektfortschritts. Anpassung von Softwareprozessen Fragestellung: Anwendbarkeit von standardisierten Softwareprozessen im konkreten Projekt? Antwort: Standardprozesse eher schwer direkt einsetzbar. Prozess Tailoring (bezogen auf der jeweilige Projekt) Anpassung eines generischen Entwicklungsprozesses an individuelle, spezifische Projektgegebenheiten. Ersetzen einzelner Prozessschritten durch passende alternative Lösungen Wiederverwendung von Best-Practices (Methoden / Tools). Erfordert erfahrene Projektleiter! Fundiertes Verständnis des Modellaufbaus erforderlich! Berücksichtigung von definierten Tailoring-Kriterien und Produktabhängigkeiten wichtig! Prozess Customization (Standardisierung) Anpassung des Vorgehensmodells an unternehmensspezifische Gegebenheiten (Unternehmensstandards) und an Projektstandards (ähnliche Projekte). Verallgemeinerte Form des Tailorings. Diese angepassten Prozesse dienen als Grundlage für projektspezifisches Tailoring. Die Kompatibilität zum zugrunde liegenden Prozess muss sichergestellt werden! Zusammenfassung Softwareprozesse und Vorgehensmodelle ermöglichen vorhersagbare und nachvollziehbare Softwarelösungen. Sie definieren, wie ein Softwareprojekt durchgeführt wird bzw. in welcher Reihenfolge die einzelnen Phasen ablaufen. Systematische Prozesse sind durch ihre Struktur plan-driven und orientieren sich eher an Abläufen mit Schwerpunkt auf Produkten und Dokumentation. Beispiele: Wasserfallmodell, V-Modell (XT), RUP, Inkrementelle Modelle. Agile Ansätze rücken den Kunden und seine konkreten (sich ändernden) Anforderungen in den Vordergrund. Beispiele: extreme Programming, SCRUM. Durch Tailoring wird ein allgemeines Modell auf ein individuelles Projekt angepasst. Customization ermöglicht die Erstellung unternehmensspezifischer Vorgehensmodelle für gleichartige Projekte / Produktgruppen. Seite 14

15 Block 8-1 Qualitätssicherung allgemein Begriffsdefinition Validierung & Verifikation Validierung = Wurde das richtige Produkt entwickelt?, z.b. Akzeptanz- und Abnahmetests (Prüfung gegen Anforderungen) Verifikation = Wurde das Produkt richtig entwickelt?, z.b. Komponententests (Prüfung gegen Spezifikation) Grundsätzliches Testen zielt darauf ab, Fehler zu finden (fehlende, falsche oder inkonsistente Informationen) und nicht der Nachweis, dass das Produkt funktioniert. Die zentralen Fragestellungen eines Testers sind - Wie kann ein Softwareprodukt fehlschlagen? - Mit welchen Szenarien kann ich das Produkt in einen instabilen, nicht mehr vorhersehbaren Zustand bringen? Für die Umsetzung von Qualität und deren Sicherung sind in Projekten notwendig: - Testbare Anforderungen (Definition der Funktionen und Qualitäten) - Verfolgbare Entwicklung der Anforderungen (mit Modellen) in testbare Produkte. Testen ist keine zusätzliche Aktivität am Ende des Softwareprojekts sondern begleitet das Projekt laufend! Block 8-2 Statische Methoden der Qualitätssicherung Begriffsdefinition Review Ein Review ist ein [..] formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesen kommentiert oder genehmigt werden. Dienen also vor allem zur qualitativen Beurteilung von Produkten und Prozessen, die quantitativ nur schwer oder gar nicht beurteilt werden können (z.b. Modelle, Dokumente) Unterschiedliche Ausprägungen von Reviews zielen auf unterschiedliche Ziele ab. Arten von Reviews Seite 15

16 Block 8-2 Statische Methoden der Qualitätssicherung (Fortsetzung) Rollen bei Reviews Moderator ( keeper of the process ): Leiter des Reviews Leser ( keeper of focus and pace ) Gutachter ( Reviewer ): Kommentierung des Reviewobjektes. Schreiber ( preserver of knowledge ): Verfasst Protokoll (Notizen während des Reviews) Autor ( author ): Klärung offenener Fragen. Keine Kommentier-/Rechtfertigung der Lösung. Ablauf eines Rewiews Planung ( planning phase ) Initialisierung ( initialisation phase ) Vorbereitung ( preparation phase ) Reviewsitzung ( review ) Sammlung im Team ( meeting ) Reviewbericht ( reporting ) Nacharbeit ( re-work ) Mit Reviews verwandte Tätigkeiten Inspektion (Ziel: Behebung von konkreten Mängeln) - Bedingung: Leser ist nicht Autor Walkthrough (Ziel: Behebung von konkreten Mängeln) - Bedingung: Autor ist Leser & Moderator Audit (Ziel: Überblickende Kontrolle) - Bedingung: Planung durch externe Personen, Projektmitarbeiter nur als Information Block 8-3 Testansätze & Test-Driven Development Elemente der Testfallbeschreibung Beschreibung ist die Komponente im System und eine Funktion (Ablauf aus Anforderungen). Vorbedingungen existieren oder eben nicht. Eingabewerte sind konkrete Parameterbeschreibungen (Äquivalenzklassen). Aktionen sind Aktivitäten zur Eingabe der Werte. Erwartete Ergebnisse sind Zustände und Ausgabeparameter. Ergebnisse zeigen Abweichungen zum tatsächlichen Ergebnis. OK/NOK zeigt ob der Test erfolgreich durchläuft. Grundlegende Testtechniken/-stufen Unit Test: Fokus auf Komponenten und Prüfung auf Übereinstimmung zwischen der Umsetzung der Komponente und technischer Spezifikation ( lebendige Dokumentation ). Integrationstest: Fokus auf Interfaces und Verbindungen zwischen Komponenten innerhalb des (Sub)Systems (inkrementelles Testen vorzuziehen). Systemtest: Übereinstimmung zwischen funktionalen und technischen Bedingungen des Gesamtsystems (nahe an der Zielplattform). Regressionstest: Testen von geänderten Komponenten. Dadurch sollen Fehler, die durch Änderungen, z.b. auch durch Fehlerkorrektur, entstanden sind, verhindert werden. Akzeptanztest: Übereinstimmung der Anforderungen in der Zielumgebung des Kunden. Installationstest: Identifizieren von Fehlern während der Installation. Seite 16

17 Block 8-3 Testansätze & Test-Driven Development (Fortsetzung) Teststrategien/-arten Black Box Tests Basiert auf Spezifikation. Wissen über innere Struktur ignoriert. Data-driven (Input/Output). Anforderungsüberdeckung. Äquivalenzklassenbildung. Keine genaue Fehlerortung möglich. White/Glass Box Tests Basiert auf Code. Wissen über innere Struktur notwendig. Logic-driven. Kontrollflussüberdeckung. Äquivalenzklassen von internen Verzweigungen und Schleifen. Ermöglicht Fehlererkennung und -lokalisierung. Äquivalenzklassen Gleiches Verhalten aus einer Menge von Eingabedaten mit demselben Ergebnis Auswahl eines repräsentativen Wertes zur Reduktion der Testfälle. Jede Klasse(-nkombination) sollte mindestens einmal getestet werden. Dadurch sinkt die Anzahl der Testfälle und somit der Testaufwand. Testfälle müssen gültige (Normalfall, Sonderfall) UND ungültige Eingabewerte (Fehlerfall) berücksichtigen. Beispiel: Anforderung = i>15 3 Äquivalenzklassen Grenzwertanalyse Spezialfall einer Äquivalenzklasse. Geeignete Auswahl der Repräsentanten in der Nähe der Datengrenzen, d.h. Grenzwerte werden als Klassenrepräsentanten gewählt je Klassengrenze ein Testfall. Beispiel: Anforderung = 18 < Alter (ungültig), 19 (gültig), 65 (gültig) & 66 (ungültig) Wertbeitrag von Softwaretests Zentrale Fragestellung: Ist jeder Testfall, jeder Fehler, jede Anforderung gleich viel wert? NEIN, das heißt Value-Based Testing ist vorrangig. Ziel: Vorrangig Unit Tests als Basis, drauf aufbauende ein geringerer Anteil an System und Integrationstests. Seite 17

18 Block 8-3 Testansätze & Test-Driven Development (Fortsetzung) Test-Driven Development Prozessablauf: 1. Think: Spezifikation des Tests. 2. Red: Implementierung des Tests (Test schlägt fehl!). 3. Green: Implementierung der zu testenden Klasse. (Test ist erfolgreich!) 4. Refactor: Veränderung einer Implementation Funktionalität bleibt erhalten. Zusammenfassung TDD als Basis für zielorientierte Software-Entwicklung (Implementierung und QS). Brauchbare Modelle unterstützen das Herstellen effektiver und effizienter Testfälle: - Datenmodellierung (Datenbank) - Datenfluss und Kontrollfluss (Business Logic) - Zustandsübergangsmodelle (z.b. GUI) Reviews helfen die Anforderungen und Modelle vorab zu überprüfen, um eine solide Basis für Testfälle herzustellen. Die Zeit für Unit Tests ist wohl investiert, da sie Integrationstests wesentlich vereinfachen (bottom-up testing). Test Cases sind living documents unterstützen die Kommunikation innerhalb des Teams. Block 9 Persistenzstrategien Grundsätzliche Fragestellungen Soll es eine Trennung zwischen Logik und Daten geben? Sind die zu speichernden Daten strukturiert, semi-strukturiert oder gar unstrukturiert? Grundsätzliche Strategien Es gibt nicht die perfekte Lösung. If you only have a hammer, everything tends to become a nail. Wichtig: Datenstrukturen überleben meist viele Softwaregenerationen! Reine, abstrakte Langzeitspeicherung von Vorteil Schichtenarchitektur Zwei-Schichten-Architektur Präsentationsschicht Anwendungs-/Datenschicht Drei-Schichten-Architektur Präsentationssc hicht Anwendungs-/Logikschicht Datenschicht - Thin-Client ( Heavy Server vs. Server per Layer) / Fat-Client (Data-Server) Data Access Object Pattern Interface Implementation Transfer/Domain Object & Business Object Seite 18

19 Block 9 Persistenzstrategien (Fortsetzung) Data Access Object Pattern Arten der Datenspeicherung Objektorientierte Datenbanken - Vorteile: Nahe an objektorientierten Sprachen (kein Mapping), schnelle DB-Entwicklung - Nachteile: lediglich kleine Anzahl erprobter Systeme (db4o, Cache), keine standardisierte Abfragesprache, keine Open Source Systeme, Versionshandling? Rationale Datenbanken - Vorteile: Neutrale Art der Datenspeicherung, hoch erprobt, große Anzahl an verfügbaren Systemen, Abfragesprachen und (Supporting) Tools (Office Pakete) - Nachteil: Schwelle zwischen Objekten & Relationen (2 verschiedene Modelle/Schemata) No SQL - Schemafrei, Fokus auf Skalierbarkeit nicht auf Konsistenz ( eventually consistent ) Clientabstraktion: Webservices / REST - REST = Representational State Transfer (Basierend auf HTTP [get, post, put, delete]) Stateless, Cacheable, Scaleable, alle Datentypen können transferiert werden - Webservices: XML/Text als Nachricht mit Antworten Speicherung in Clouds - Nutzung von Webservices eines Anbieters ohne eigene Speicher-Infrastruktur - Ziele: Hohe Performance, Hohe Verlässlichkeit, Einfachheit - Beispiel: Amazon S3 Objektrelationales Mapping Problem: Mapping Objekte Tabellen (inkl. Assoziationen), Zugriffsstrategie? Beispiele: mybatis (Data Mapper), Hibernate (voller O/R-Mapper Vorteil: Trennung von relationalen Modell und objektorientierten Modell Geringere Abhängigkeit von der Datenbank Nachteile: Komplexität, Tabelle-Mapping-Problem (Tabelle pro Klasse/konkreter Klasse?), Zeilenidentität (nicht bestimmbar) versus Speicheridentität (bestimmbar), vollständige Trennung zwischen Datenbank und OO oft nicht möglich Block 10 Projektmanagement (Teil 2) Motivation Prozesstheorien: Geben eine Erklärung darüber, wie das Verhalten gesteuert wird, warum ein bestimmtes Verhalten zur Erreichung eines definierten Ziels gewählt wird Inhaltstheorien: Beschreiben Bedürfnisse, Antriebe und Ziele der Menschen - Monothematische Theorien (einzelnes Motiv ausschlaggebend, z.b. Freud: Sexualtrieb) - Polythematische Theorien (mehrere Grundmotive in unterschiedlicher Rangordnung) z.b. Motivationspyramide von Maslow, ERG-Modell, Zufriedenheitstheorie von Herzberg Seite 19

20 Block 10 Projektmanagement (Teil 2) (Fortsetzung) Motivationspyramide nach Maslow Abraham Maslow (1954) geht von fünf Kategorien menschlicher Bedürfnisse aus, welche eine Hierarchie der Dringlichkeiten bilden. Erst wenn eine Stufe in einem gewissen Ausmaß befriedigt ist, wird die darauf aufbauende verfolgt. In dieser Form überholt aber als Ansatzpunkt hilfreich. Produktionsfaktor Mensch Mehr als eine Ressource Mitarbeitermotivation hat besondere Bedeutung Produktivität: Erbrachte Leistung im Verhältnis zur aufgewendeten Zeit; Fehler: - Personal zu mehr Arbeit anhalten - Prozess der Produktentwicklung automatisieren - Qualitätsmaßstäbe für das Produkt modifizieren (i.e. reduzieren) - Vorgehensweisen standardisieren Kontraproduktive Maßnahmen (Verringerung der Arbeitsmotivation, Folge: Fluktuationen) Typische Fluktuationszahlen zwischen 33% und 80%, durchschnittliche Beschäftigungszeit zwischen 15 und 38 Monaten. Der Mythos der Austauschbarkeit wird durch die Maßeinheit Personen-Monat zur Angabe der Projektdauer beschrieben. Dahinter steht die Vorstellung, dass sowohl Personen als auch Monate beliebig austauschbar sind. Diese Vorstellung hat aber nur eine (annähernde) Berechtigung bei Arbeiten, die ohne Kommunikation ausführbar sind! Umwelt-Faktor: Anwesenheitszeit vs. Zeit mit vollem Arbeitseinsatz (Flow nach 15 min) Auswahl von Mitarbeitern (1) Job specification - Auflistung der Anforderungen des Jobs (2) Job holder profile - Auflistung der Anforderungen an die Person, die den Job ausfüllen soll. zum Beispiel: Qualifikationen, Berufserfahrung, Ausbildung,... (3) Bewerbungen einholen - Schalten der Stellenausschreibung in einem geeigneten Medium - Das geeignete Medium lässt sich u.u. aus dem Job holder profile ableiten (4) Auswertung der Bewerbungen - Vergleich der Lebensläufe mit dem Job holder profile - Ungeeignete Kandidaten frühzeitig ausscheiden (5) Auswahl der Mitarbeiter - Durch Portfolio (Auswahl von Produkten ihrer bisherigen Tätigkeiten) - Durch Eignungstests, Anhörungen, Interviews Sieben Wege um Teambildung zu verhindern Defensives Management Bürokratie Physikalische Trennung Zersplitterung der Zeit des Mitarbeiter Formen der Teamorganisation die klassische hierarchische Organisation die typische Matrix-Organisation das Chef-Programmierer -Team Qualitätsreduktion der Produkte (geringere Identifikation) Scheintermine Cliquenzerschlagung das offen strukturierte Team das SWAT-Team das XP-Team Seite 20

ablauforientiert: Erläutern Sie anhand einer Skizze das Grundkonzept von SCRUB Sprints.

ablauforientiert: Erläutern Sie anhand einer Skizze das Grundkonzept von SCRUB Sprints. Was ist ein Projekt und durch welche Merkmale ist ein Projekt gekennzeichnet? zeitlich begrenztes Vorhaben klare Ziele einmalig komplex mit verschiedenen Methoden/Techniken erfordert oft interdisziplinäre

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

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

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. 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/

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Christoph Redl Quelle der Fragen: http://www.informatik-forum.at/showthread.php?t=54097 1 SCRUM Prinzip + Vorteile

Mehr

Grundlagen Software Engineering

Grundlagen 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

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

EINFÜ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. 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

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft 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

Mehr

Informationswirtschaft II

Informationswirtschaft 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

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. 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

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Übung Einführung in die Softwaretechnik

Ü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

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.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

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Anne Thomas TU Dresden Dr. B. Demuth Pre Press GmbH (Dresden) T. Reuter Gliederung Einleitung Vorgehensweise Kontext

Mehr

Übungsaufgaben zum Software Engineering: Management

Ü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

Mehr

Grundlagen des. Grundlagen des Projektmanagements. 0 Grundlagen der Grundlagen 1 Projektstart

Grundlagen des. Grundlagen des Projektmanagements. 0 Grundlagen der Grundlagen 1 Projektstart Grundlagen des s Grundlagen des s Vorlesung an der Technischen Universität Wien; März 2004 Dr.H.Karnovsky Dr.H.Karnovsky 1 0 Grundlagen der Grundlagen 1 Projektstart Vorlesung 11.3.2004 3 Projektverfolgung

Mehr

Das Wasserfallmodell - Überblick

Das 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

Mehr

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

Mehr

Software Engineering & Software Prozesse Teil 1b: Life-Cycle Phasen

Software Engineering & Software Prozesse Teil 1b: Life-Cycle Phasen Vortragsreihe Software Engineering for Everyday Business Software Engineering & Software Prozesse Teil 1b: Life-Cycle Phasen Dietmar Winkler, Michael Pernkopf Technische Universität Wien Institut für Softwaretechnik

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009 - Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

SE Besprechung. Übung 3 Softwareprozesse

SE Besprechung. Übung 3 Softwareprozesse SE Besprechung Übung 3 Softwareprozesse SE, 08.11.11 Mengia Zollinger Analyse der Systemkomponenten(3 Punkte) Mögliche Ansätze: 3-Schichten-Architektur (tree-tier-architecture) Präsentation Anwendungslogik

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Entwicklungsmethoden

Entwicklungsmethoden Slide 3.1 Entwicklungsmethoden Prof. Dr. Josef M. Joller jjoller@hsr.ch Development Methodologies Prof. Dr. Josef M. Joller 1 Session 3 Slide 3.2 SOFTWARE LIFE-CYCLE MODELLE Development Methodologies Prof.

Mehr

Der 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 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

Mehr

READY-STEADY-DONE! Der Product Owner are you READY for agile?!

READY-STEADY-DONE! Der Product Owner are you READY for agile?! READY-STEADY-DONE! Der Product Owner are you READY for agile?! Susanne Mühlbauer HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Neue Ideen sind

Mehr

Testen. SEPR Referat: Testen - Oliver Herbst

Testen. SEPR Referat: Testen - Oliver Herbst Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt

Mehr

Was versteht man unter einem Softwareentwicklungsmodell?

Was 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

Mehr

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Objekt Objekt kapselt Variablen und Routinen Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Eigenschaften jedes Objekts: Identität (identisch = mehrere

Mehr

Prozess-Modelle für die Softwareentwicklung

Prozess-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

Mehr

Projektmanagement Projektablauf

Projektmanagement Projektablauf Projektmanagement Projektablauf Inhalt Was ist ein Projekt? Projektphasen Projektablauf Wichtige Begriffe Zusammenfassung 2 Warum Projektmanagement? Von der Seminararbeit......bis zum Urlaub...alles eine

Mehr

Software Engineering. 3. Analyse und Anforderungsmanagement

Software 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

Mehr

Lohnt sich Requirements Engineering?

Lohnt sich Requirements Engineering? Lohnt sich Requirements Engineering? Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss Oleksandr Kazandzhi Gliederung Einleitung Messen

Mehr

Architektur und Qualität. Tjard Köbberling

Architektur 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

Mehr

Projektmanagement iterativer Projekte

Projektmanagement iterativer Projekte Übersicht Motivation zum iterativen Vorgehen Anleitung zur U Ca getriebenen Vorgehenswei Praktische Tipps Zusammenfassung Projektmanagement iterativer Rainer Schmidberger Universität Stuttgart Institut

Mehr

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework Einführung MSF MOF Microsoft Solutions Framework Microsoft Operations Framework Daniel Dengler CN7 Agenda Unterschied MSF - MOF Microsoft Solutions Framework Elementare Komponenten grundlegende Richtlinien

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile 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

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé Von Requirements zus gç~åüáãkpåüìäò]èì~äáíóé~êâkçé QualityPark Ihr Partner im Lifecycle Management Process Management Requirements Engineering IT & Development Process Expertise Process Implementation

Mehr

Übungen zur Softwaretechnik

Ü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

SEA. Modellgetriebene Softwareentwicklung in der BA

SEA. Modellgetriebene Softwareentwicklung in der BA SEA Modellgetriebene Softwareentwicklung in der BA MDA bei der BA Ziele/Vorteile: für die Fachabteilung für die Systementwicklung für den Betrieb Wie wird MDA in der BA umgesetzt? Seite 2 MDA bei der BA

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Some Software Engineering Principles

Some 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

Mehr

Software - Testung ETIS SS05

Software - Testung ETIS SS05 Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks

Mehr

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Software Engineering

Software Engineering Software Engineering Grundlagen, Menschen, Prozesse, Techniken von Jochen Ludewig, Horst Lichter 1. Auflage Software Engineering Ludewig / Lichter schnell und portofrei erhältlich bei beck-shop.de DIE

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

Mehr

Best Practices für RM/RE in einem Prozess Framework Thomas Schröder

Best Practices für RM/RE in einem Prozess Framework Thomas Schröder Best Practices für RM/RE in einem Prozess Framework Thomas Schröder 1 Die Herausforderung bewährte Praktiken effektiv zu nutzen Unterschiedliche Quellen in unterschiedlichen Formaten Schwierig anzupassen

Mehr

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 1 Software Engineering: Überblick Kapitel 1 Software Engineering: Überblick 2 Ziele Verstehen, womit sich die Disziplin

Mehr

Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen

Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen White Paper Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen Die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Software Engineering

Software 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,

Mehr

Software Engineering. 11. Einführung und Wartung

Software Engineering. 11. Einführung und Wartung Software Engineering 11. Einführung und Wartung Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Testen

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (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

Mehr

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit.

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. BEKA: Frankfurt, 25. Oktober 2012 T-Systems Angebot Umsetzung des globalen Telematikprojekts für den ÖPNV im Großherzogtum Luxemburg.

Mehr

Agiles EAM. Agiles Enterprise Architecture Management. Mit Weitsicht zur Übersicht. Matthias Heinl Senior Consultant IT-Architekturen IT-Strategien

Agiles EAM. Agiles Enterprise Architecture Management. Mit Weitsicht zur Übersicht. Matthias Heinl Senior Consultant IT-Architekturen IT-Strategien Agiles EAM Agiles Enterprise Architecture Management Mit Weitsicht zur Übersicht Matthias Heinl Senior Consultant IT-Architekturen IT-Strategien coniatos AG IT-Management Consulting Wiesbaden Agenda Einleitung

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Service Virtualisierung

Service Virtualisierung Service Virtualisierung So bekommen Sie Ihre Testumgebung in den Griff! Thomas Bucsics ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master,

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master, TFS Customzing in der Praxis Thomas Gugler ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com Thomas Gugler seit 2005 bei

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (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

Mehr

Software- und Systementwicklung

Software- und Systementwicklung Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm

Mehr

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

IT-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

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Code-Reviews. Code-Generierung. Code-Generierung. Code-Reviews. als Bestandteile des Entwicklungsprozesses

Code-Reviews. Code-Generierung. Code-Generierung. Code-Reviews. als Bestandteile des Entwicklungsprozesses Datenbanken-Seminar: Vortrag am 10. Januar 2003 als Bestandteile des Entwicklungsprozesses und : Gemeinsamkeiten? und : Gemeinsamkeiten? Gemeinsame Ziele und : Gemeinsamkeiten? Gemeinsame Ziele Kontrolle

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at www.celix.at September 2015 celix Solutions GmbH Spezialist für Team Collaboration und IT Prozess Management Agile

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

Mehr

Softwarearchitekturen I Softwareentwicklung mit Komponenten

Softwarearchitekturen I Softwareentwicklung mit Komponenten Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1 Beispiel: Bibliothekssystem

Mehr

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile 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

Mehr

Ein Vortrag für den Arbeitskreis Requirements GI München am 15.10.2012 Referent: Dipl.-Ing. (FH) Paul Huber, MBA http://www.gi-muc-ak-req.

Ein Vortrag für den Arbeitskreis Requirements GI München am 15.10.2012 Referent: Dipl.-Ing. (FH) Paul Huber, MBA http://www.gi-muc-ak-req. Ein Vortrag für den Arbeitskreis Requirements GI München am 15.10.2012 Referent: Dipl.-Ing. (FH) Paul Huber, MBA http://www.gi-muc-ak-req.de Das bin ich Dipl.-Ing. (FH) Paul Huber, MBA seit 2006 Ingenieurbüro

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

Qualitätsmanagement im Projekt

Qualitä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

Mehr

Use Cases. Use Cases

Use 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

Mehr

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13 Service Transition Martin Beims WKV SS13 Karsten Nolte Inhalt Einführung & Ziele Transition Planning & Support Change Management Service Asset & Configuration Management Release & Deployment Management

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

15 Verwaltung von Anforderungen (Requirements Management)

15 Verwaltung von Anforderungen (Requirements Management) 15 Verwaltung von Anforderungen (Requirements Management) Was ist Requirements Management? Planung und Lenkung des RE-Prozesses Konfigurationsmanagement für Anforderungen Identifikation Änderungs- und

Mehr