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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

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

Ü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

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

SEPM SS13 Fragenkatalog ausgearbeitet

SEPM SS13 Fragenkatalog ausgearbeitet SEPM SS13 Fragenkatalog ausgearbeitet Vorwort: Ich habe mir die Mühe gemacht, den bestehenden Fragenkatalog von den vorigen Test auszuarbeiten. Ich kann nur jedem empfehlen es min. 1 selbst zu schreiben,

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

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

Ü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

Software Engineering & Software Prozesse Teil 1c: Ausgewählte Softwareentwicklungsprozesse

Software Engineering & Software Prozesse Teil 1c: Ausgewählte Softwareentwicklungsprozesse Vortragsreihe Software Engineering for Everyday Business Software Engineering & Software Prozesse Teil 1c: Ausgewählte Softwareentwicklungsprozesse Dietmar Winkler, Michael Pernkopf Technische Universität

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

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

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

Projektmanagement: Prozessmodelle

Projektmanagement: Prozessmodelle Projektmanagement: Prozessmodelle Martin Wirsing Institut für Informatik Ludwig-Maximilians-Universität München WS 2006/07 Ziele Wichtige Prozessparadigmen und Vorgehensmodelle wiederholen und in Zusammenhang

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Softwaretechnik Prozessmodelle

Softwaretechnik Prozessmodelle Softwaretechnik Prozessmodelle Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin Celine: They enjoy the goal but not the process. But the reality of it is that the true work of improving things

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

Management von Anforderungen im Rational Unified Process (RUP)

Management von Anforderungen im Rational Unified Process (RUP) Management von Anforderungen im Rational Unified Process (RUP) Peter Fröhlich ABB DECRC 69115 Heidelberg Fröhlich-8/98-1 Themen: Was ist RUP? RM im RUP Core Workflows Dokumente Tools Erfahrungen RUP Objectory

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

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

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

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center Ihr starker IT-Partner. Heute und morgen PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr PRINCE2 TAG 2011 Peter Morwinski, Leiter Technologie Center INHALT PRINCE2 und V-Modell XT Einleitung

Mehr

Das V-Modell: Produkte 1/5

Das V-Modell: Produkte 1/5 Das : Produkte 1/5 Problem-Beschreibung, Lastenheft Beschreibung des Problems/der Probleme, das/die gelöst werden soll Quellen: Markt-Analyse, Marketing, Kunden-Zirkel etc. Kunden-Anforderungen, Pflichtenheft

Mehr

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

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

Scrum und professionelles Requirements Engineering

Scrum und professionelles Requirements Engineering Scrum und professionelles Requirements Engineering Dr. Martin Mandischer (Prokurist, Professional Scrum Trainer) Jens Trompeter (Vorstand, Certified Scrum Professional) Gründung im Jahr 2003 Mehr als 160

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

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

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

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

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

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Scriptbasierte Testautomatisierung. für Web-Anwendungen

Scriptbasierte Testautomatisierung. für Web-Anwendungen Scriptbasierte Testautomatisierung für Web-Anwendungen Scriptbasierte Testautomatisierung + Web-Anwendung: Erstes Einsatzgebiet, Ergebnisse aber allgemein übertragbar + Test aus Benutzersicht - Nicht Unit-Test,

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

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

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL INGTES AG Bahnhofstr. 94 CH 5000 Aarau Tel. +4162 836 30 70 www.ingtes.com PRODUKTENTWICKLUNG NACH DEM INGTES-PROZESSMODELL 2 1 PRODUKT- ENTWICKLUNG Bei

Mehr

Softwaretechnik (Medieninformatik) Überblick

Softwaretechnik (Medieninformatik) Überblick Softwaretechnik (Medieninformatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 Überblick UML-Diagramme

Mehr

Agile Softwareentwicklung. Yelve Yakut

Agile Softwareentwicklung. Yelve Yakut Agile Softwareentwicklung Yelve Yakut Index Projekte Vorgehensmodelle Agilität Scrum Feature Driven Development 20.05.08 Agile Softwareentwicklung #2 Projektplanung Von 210 Projekten im Zeitraum von 1997

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

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

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

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

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

Teil VII. Software Engineering

Teil VII. Software Engineering Teil VII Software Engineering Überblick 1 Einführung 2 Der Softwareentwicklungsprozess 3 Methoden und Werkzeuge Eike Schallehn Grundlagen der Informatik für Ingenieure 2008/2009 7 1 Einführung Die Softwarekrise

Mehr

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1

V-Modell. Dipl. Wirtsch. Ing. Alexander Werth 11-1 V-Modell Dipl. Wirtsch. Ing. Alexander Werth Software Engineering 11-1 Was ist das V-Modell? Das V im V-Modell steht für Vorgehensmodell. Umfangreiches Dokument. Softwaretool zur Unterstützung. Vorgabe

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Software-Engineering

Software-Engineering SWE6 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 6: Projektmanagement Wasserfallmodell SWE6 Slide 2 Wasserfallmodell Zeitliche Einordnung in Breiten-/Tiefenraster Funktionale Breite

Mehr

Agile Softwareentwicklung und Usability Wie mit Best Practices eine Brücke geschlagen werden kann

Agile Softwareentwicklung und Usability Wie mit Best Practices eine Brücke geschlagen werden kann Agile Softwareentwicklung und Usability Wie mit Best Practices eine Brücke geschlagen werden kann UIG-Frühjahrstagung 2015 15. März 2015, Mannheim Dominik Magin, Hartmut Schmitt 1 Agile Entwicklungsvorgehen

Mehr

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt Produktqualität in agilen Entwicklungsvorgehen BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt 1 Motivation 2 Agile Entwicklungsvorgehen Status Quo vorwiegend eingesetzte

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

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

Wieviel Usability Engineering braucht das Software Engineering?

Wieviel Usability Engineering braucht das Software Engineering? Wieviel Usability Engineering braucht das Software Engineering? Prof. Dr. Institut für Informatik Neuenheimer Feld 348 69120 Heidelberg http://www-swe.uni-heidelberg.de paech@informatik.uni-heidelberg.de

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

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

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014

Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Evolutionsprozesse Dr. Thorsten Arendt Marburg, 23. Oktober 2014 Überblick Betrachtung der bekannten Softwareentwicklungsprozesse bezüglich Software-Evolution Evolutionsprozesse Techniken für Software-Evolution

Mehr

27. März 2013. Einführung Requirements Engineering: Rückblick und Ausschau

27. März 2013. Einführung Requirements Engineering: Rückblick und Ausschau 27. März 2013 Lukas Müller 27.3.2013 27. März 2013, p 3 Schwerpunkte Umfeld Tecan Aufbau von Requirements Engineering Ausschau 27. März 2013, p 4 Umfeld Tecan 27. März 2013, p 5 Tecan Hauptsitz in Männedorf,

Mehr

Softwarepraktikum. Gernot A. Fink SS 2005

Softwarepraktikum. Gernot A. Fink SS 2005 Softwarepraktikum Gernot A. Fink SS 2005 Einführung Wichtige Grundbegriffe Was ist Softwareengineering? Software- und Projektentwicklung Anfordernugen and Softwareentwicklung Softwareprozesse und Vorgehensmodelle

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

Testmanagement bei SAP-Projekten

Testmanagement bei SAP-Projekten Testmanagement bei SAP-Projekten Erfolgreich Planen Steuern Reporten bei der Einführung von SAP-Banking von Alberto Vivenzio, Domenico Vivenzio 1. Auflage Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck

Mehr

Fabian Schmengler, Dr. Nikolai Krambrock

Fabian Schmengler, Dr. Nikolai Krambrock Fabian Schmengler, Dr. Nikolai Krambrock Herausforderungen bei Konzeption und Test von Magento-Modulen Wechsel von C# zu Magento Ursprünglich Entwicklung von Thick-Client Applikationen mit C# Vollständiger

Mehr

Requirements Engineering bei IXOS - mit Beteiligung von User Experience

Requirements Engineering bei IXOS - mit Beteiligung von User Experience Requirements Engineering bei IXOS - mit Beteiligung von User Experience MMC Paderborn, 2004-09-07 Petra Kowallik User Interaction Designer IXOS Software AG Copyright 1995-2004 Open Text Inc. All rights

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

Softwareentwicklung mit UML

Softwareentwicklung mit UML Softwareentwicklung mit UML Die Unified Modeling Language im Projekteinsatz 2.12.2003, Seite 1 Übersicht 1 Einleitung 2 Die Unified Modeling Language (UML) 3 Vorgehensmodelle und UML 4 Ausblick 4.1 UML

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

mimacom path Ihr Nutzen www.mimacom.com

mimacom path Ihr Nutzen www.mimacom.com ist ein Lösungspaket, mit dem sich das ganze Application Lifecycle Management abdecken lässt: Vom Requirements Engineering über die agile Abwicklung von Projekten bis hin zum Service Management. Der ganzheitliche

Mehr

Software Engineering & Software Prozesse

Software Engineering & Software Prozesse Vortragsreihe Software Engineering for Everyday Business Software Engineering & Software Prozesse Dietmar Winkler, Michael Pernkopf Technische Universität Wien Institut für Softwaretechnik und Interaktive

Mehr

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung Übersicht s s Gregoire Kemgne 1 Motivation Problem: Software wird immer größer und komplexer, dadurch ist diese immer schwerer zu überschauen Ein Projekt benötigt mehr Zeit und/oder Entwickler. Lösung:

Mehr

Modellgetriebene agile BI-Vorgehensweise

Modellgetriebene agile BI-Vorgehensweise Modellgetriebene agile BI-Vorgehensweise Thomas Neuböck Konrad Linner 12.11.2013 Inhalt Anforderungen und Lösungsansatz Agile Vorgehensweise Orientierung nach Fachthemen Architekturrahmen Modellorientierung

Mehr

>EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements

>EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements >EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements 6. Januar 2014 >Agenda Motivation EasyMain Methoden, Standards und Prozesse bei EasyMain Folie

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

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

Anforderungen dokumentieren, validieren und verwalten

Anforderungen dokumentieren, validieren und verwalten Anforderungen dokumentieren, validieren und verwalten iks-thementag: Requirements Engineering 16.11.2010 Autoren Christoph Schmidt-Casdorff Carsten Schädel Agenda Einleitung Anforderungen dokumentieren

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr