This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Klassische Fehler in der Software-Entwicklung:Es wird direkt mit der Codierung angefangenDas Vorgehensmodell fehlt bzw. wird nicht befolgtDie Terminvorgaben sind unrealistischDie Weiterbildung der Mitarbeiter ist nicht zielgerichtetAuswahl und Einsatz der Werkzeuge bzw. Methoden ist unzureichendvorbereitetEin Risikomanagement wird nicht betriebenEine Abnahme der Phasenergebnisse erfolgt nichtEs wird nicht systematisch bzw. unzureichend getestetDie Anforderungen und Qualitätsmerkmale werden nicht festgelegt
Motivation: Warum Management? (5)
Quelle: Interne Untersuchung bei Bosch
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
Unmittelbarer Bezug zu VorlesungsthemenMittelbarer Bezug zu Vorlesungsthemen
Klassische Fehler in der Software-Entwicklung (Fortsetzung):Es fehlen eindeutige BegriffsdefinitionenDie Systemarchitektur ist gar nicht oder nur mit großem AufwanderweiterbarDas System ist nicht modular aufgebaut, die Daten sind nichtgekapseltProgrammier-Standards bzw. -Richtlinien werden nicht beachtetDie Namensvergabe ist ungünstigDie Dokumentation fehlt ganz, ist veraltet oder nicht adäquatDie Schulung der Anwender wird vernachlässigtDas Konfigurationsmanagement ist unzureichend
Quelle: Interne Untersuchung bei Bosch
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
Unmittelbarer Bezug zu VorlesungsthemenMittelbarer Bezug zu Vorlesungsthemen
SoftwaretechnikPrinzipien, Methoden, Techniken zur Entwicklung großerSoftwaresysteme, z.B.
AnalysemethodenDesign, ArchitekturTestverfahren
Software-QualitätssicherungTätigkeiten, die dazu dienen, den Nachweis zu erbringen, dass dieQualitätsanforderungen an die Software erfüllt sind, z.B. durch
Testfallermittlung
Software-ProjektmanagementPlanen und Steuern eines Projekt („Klassische Managementaufgaben“)
1.1 (Motivation)Kap. 1 (Einleitung und Grundlagen)
Inhalte der Vorlesung (1/6)Kapitel 1: Einleitung und Grundlagen
1.1 Motivation1.2 Überblick über die Vorlesung1.3 Grundbegriffe1.4 Ziele und Aufgaben des Softwaremanagement1.5 Vorgehensmodelle für die Softwareentwicklung
Kapitel 2: Projektplanung2.1 Ziele und Inhalte der Planung2.2 Das Projektziel2.3 Organisatorische Aspekte von Projekten2.4 Projektstrukturplan2.5 Netzplantechnik2.6 Ressourcenplanung2.7 Werkzeugunterstützung: Microsoft Project2.8 Der Projektmanagement-Plan
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
Inhalte der Vorlesung (2/6)Kapitel 3: Aufwands- und Kostenschätzung
3.1 Motivation3.2 Überblick über Kostenschätzungsverfahren3.3 Function Point Methode3.4 COCOMO
Kapitel 4: Projektkontrolle und -steuerung4.1 Berichtswesen und Projektdokumentation4.2 Projektsteuerung4.3 Entscheidung4.4 Besprechungen und Präsentationen4.5 Kreativitätstechniken4.6 Projektabschluss
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
Inhalte der Vorlesung (4/6)Kapitel 7: Konfigurationsmanagement
7.1 Motivation7.2 Begriffe7.3 Änderungs- und Fehlermanagement7.4 Versions- und Variantenmanagement7.5 Auswertungen im Rahmen des Konfigurationsmanagements7.5 Werkzeugunterstützung für Konfigurationsmanagement7.6 Der Konfigurationsmanagement-Plan
Kapitel 8: Requirements Management8.1 Requirements Engineering vs. Requirements Management8.2 Aktivitäten des Requirements Management8.3 Requirements Management Systeme8.4 Beispiel eines Requirements Management-Systems: DOORS
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
Inhalte der Vorlesung (5/6)Kapitel 9: Qualitätsmanagement
9.1 Motivation und Überblick9.2 Systematisches Testen9.3 Reviews und Inspektionen9.4 Formale Verfahren9.5 Konstruktive Qualitätssicherung
Kapitel 10: Die Menschliche Komponente10.1 Leistung und Motivation10.2 Zusammenarbeit in der Gruppe
Kapitel 11: Einführung von Prozessen11.1 Motivation und Definition11.2 Organisationsentwicklung11.3 Ausgewählte Aspekte von Veränderungen11.4 Modell zur Einführung von Prozessen
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
Kapitel 12: Herausforderungen aus der PraxisVerteilte Software-Entwicklung
12.1 Motivation und Grundbegriffe12.2. Vorteile12.3. Herausforderungen12.4. Kooperationsmodelle12.5. Best Practices12.6 Aktuelle Forschungsthemen
Sicherheit und Zuverlässigkeit12.7 Einleitung und Motivation12.8 Grundlagen und Begriffe12.9 Grundlagen der Zuverlässigkeitstechnik12.10 Grundlagen der Sicherheitstechnik12.11 Überblick neuer Automotive-Standard zur funktionalen Sicherheit12.12 Sicherheits- und Zuverlässigkeitsmaßnahmen12.13 Sicherheitsanalyse-Methoden
Inhalte der Vorlesung (6/6)
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
ReferentenKapitel 1: Einleitung und GrundlagenKapitel 2: ProjektplanungKapitel 3: Projektkontrolle und -steuerungKapitel 4: Aufwands- und KostenschätzungKapitel 5: Messen und Bewerten von SoftwareKapitel 6: RisikomanagementKapitel 7: KonfigurationsmanagementKapitel 8: Requirements ManagementKapitel 9: QualitätsmanagementKapitel 10: Die menschliche KomponenteKapitel 11: Einführung von ProzessenKapitel 12: Herausforderungen aus der Praxis
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
LiteraturH. Balzert. Lehrbuch der Softwaretechnik. Band 1 und 2, Spektrum Akademischer Verlag, 2000,2008.K. Schneider. Abenteuer Software-Qualität. dpunkt.Verlag, 2007.K. Frühauf, J. Ludewig, H. Sandmayr. Software-Projektmanagement und –Qualitätssicherung. vdfHochschulverlag AG an der ETH Zürich, 4. Aufl., 2001.K. Frühauf, J. Ludewig, H. Sandmayr. Software-Prüfung. vdf Hochschulverlag AG an der ETHZürich, 6. Aufl., 2006.K. Wiegers. Software Requirements. Microsoft Press, 2nd Edition, 2003.J. Schäuffele, T. Zurawka. Automotive Software Engineering. 3. Aufl., Vieweg Verlag, 2006.B. Jenny. Projektmanagement in der Wirtschaftsinformatik. vdf Hochschulverlag AG an der ETHZürich; Auflage: 5. Aufl., 2001.N.E. Fenton, S.L. Pfleeger. Software Metrics – A Rigorous & Practical Approach. ThomsonComputer Press, 1997.H. Henrich. Management von Softwareprojekten. Vorlesungsscript Fern-Uni Hagen, 2001.M.B. Chrissis, M. Konrad, S. Shrum. CMMI for Development, Version 1.2. Addison Wesley, 2001.D. Thomas, A. Hunt. Versionsverwaltung mit CVS. Hanser Verlag, 2004.B. Poensgen, B. Bock. Function-Point-Analyse — Ein Praxisbuch. dpunkt Verlag, 2005.
1.2 (Überblick über die Vorlesung)Kap. 1 (Einleitung und Grundlagen)
... Software ist immateriellSoftware und ihre Eigenschaften sind schwer messbar/beurteilbar,Fortschrittskontrolle ist schwierig
... Ergebnisse/Zwischenergebnisse für IT-Laien oft schwer beurteilbarExterne Fortschrittskontrolle schwierigErschwerte KommunikationAnalogie: Beurteilung einer Skizze für ein Haus und eine SW-Architektur
... Software ist ”nicht stetig“Geringe Änderungen haben oft gravierende Auswirkungen
... Umfeldabhängigkeiten sind wenig erforschtAnalogie: Hausbau in Europa, Antarktis, SaharaD.h. Umfeldspezifische Anpassung der Vorgehensweise notwendig
... Wenig gesichertes Wissen über VorgehensmodelleWelches Vorgehensmodell für welches Projekt in welchem Umfeld?
1.3 (Grundbegriffe)Kap. 1 (Einleitung und Grundlagen)
OrganisierenFestlegen von Abläufen und ZuständigkeitenStichwort „Projektorganisation“Ablauforganisation: Vorgehen zur Erfüllung bestimmter FunktionenAufbauorganisation: Zuständigkeiten und GliederungDaneben: „Kleinere Organisationsobjekte“, z.B:
MeetingsProjektarchiv
Kontrollieren„Planung ohne Kontrolle ist sinnlos“Ein Projekt ist eine Regelschleife
Frühzeitiges Erkennen von Fehlentwicklungen oder unrealistischenPlanungen
Oft negatives Image (Überwachung)
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
MotivierenZentral für den Erfolg des ProjektsAnnahme: Mensch wird durch Streben nach Befriedigung vonGrundbedürfnissen motiviert (Maslow‘sche Bedürfnispyramide)
Informieren und KommunizierenMangelnde Transparenz ist oft Ursache für fehlgeschlagene ProjekteEssentiell: Zielgerichtetes Berichtswesen
Notwendige Informationen kompakt und übersichtlichAber auch: Informelle Kontakte
SteuernVerschiedene Formen des Steuerns, z.B.
Management by Objectives (Führung durch messbare Zielvorgaben)Management by Exception (Routine wird selbständig erledigt)Management by Motivation (Verbinden der individuellen Interessen mitUnternehmenszielen)
1.4 (Ziele und Aufgaben des Softwaremanagements)Kap. 1 (Einleitung und Grundlagen)
Kleine, spezialisierte AnwendungHäufig: Programmierer = NutzerKeine Notwendigkeit für explizites Projektmanagement
In den 60ernAnwendungen werden umfangreicher und komplexerSoftwareentwicklung nun in Teams (Arbeitsteilung)Aber: Keine Hilfen zur Strukturierung der Arbeit
1968 NATO Konferenz in Garmisch-Partenkirchen:Begriff Software Engineering
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Folgende Fragen sollten durch ein Vorgehensmodell beantwortetwerden
Wer? VerantwortungWas? AufgabeWarum? Begründung und ZielWann? ZeitpunktWo? Ort, Funktion oder ProduktWie? Art und Weise, AblaufWomit? ArbeitsmittelWonach? Methoden, Normen, StandardsWofür? Zielgruppe
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Lineare Abfolge mit RücksprüngenGutes Gedankenmodell (Separation of Concerns)In Reinform selten anwendbar
Probleme:Kontrolle des Projektfortschritts nach wie vor schwierigZusammenhänge zwischen Phasen wird leicht vernachlässigtTestaktivitäten werden zu sehr als (späte) Phase betrachtetIn großen Projekten vergeht viel Zeit bis das erste Produkt vorliegt
Viele Varianten des Wasserfallmodells, z.B.Mit PrototypingMehrere „Wasserfälle“ hintereinander (Evolutionäre SW-Entwicklung)
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
SE AnwenderforderungenSystemarchitekturTechnische AnforderungenSchnittstellenübersichtSchnittstellenbeschreibungIntegrationsplanSWPÄ-KonzeptBetriebsinformationen
KM KM-PlanKonfigurations-IdentifikationsdokumentDatenkatalogÄnderungsantrag/ProblemmeldungÄnderungsvorschlagÄnderungsauftragÄnderungsmitteilungÄnderungsstatuslisteProjekthistorie
Das V-Modell des Bundes 1997 (6): Beschreibung einer AktivitätSE 4.2-SW: SW-interne und -externe Schnittstellen entwerfen
Produktfluß
von nachAktivität Zustand Produkt Aktivität Zustand
SE 1 akzeptiert Anwenderforderungen — —
SE 2 akzeptiert Systemarchitektur — —
SE 3 akzeptiert Technische Anforderungen — —
SE 4.1-SW akzeptiert SW-Architektur — —
SE 4.1-SW akzeptiert Schnittstellenübersicht — —
SE 2 in Bearb. Schnittstellenbeschreibung SE 4.3-SW, SE 5-SW,KM 4.3
vorgelegt
AbwicklungDie beim Entwurf der SW-Architektur in der Schnittstellenübersicht identifizierten Schnittstellen sindin der Schnittstellenbeschreibung im einzelnen detailliert darzustellen. Bereits beschriebeneSchnittstellen sind gegebenenfalls weiter zu präzisieren.IT-Sicherheitsaspekte wie sie bereits bei der Identifikation der Schnittstellen eine Rolle spielten sindhier weiter und mit besonderer Sorgfalt zu verfolgen. Alle Schnittstellen der IT-sicherheitsspezifischenund IT-sicherheitsrelevanten SW-Komponenten/SW-Module müssen mit ihrem Zweck und ihrenParametern beschrieben werden. Die Separierung vom nicht IT-sicherheitsrelevanten Teil mußsichtbar sein.
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
V-Modell XT Philosophie: Ziel- und ErgebnisorientierteVorgehensweise
Produkte stehen im MittelpunktProjektdurchführungsstrategien undEntscheidungspunkte geben die Reihenfolge derProduktfertigstellung und somit die grundlegendeStruktur des Projektverlaufs vor.Die detaillierte Projektplanung und -steuerung wird aufder Basis der Bearbeitung und Fertigstellung vonProdukten durchgeführt.Für jedes Produkt ist eindeutig eine Rolle verantwortlichund im Projekt dann eine der Rolle zugeordnete Person.Die Produktqualität ist überprüfbar durch definierteAnforderungen an das Produkt und expliziteBeschreibungen der Abhängigkeiten zu anderenProdukten.
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
V-Modell XT: Vorgehensbausteine als modulare Elemente
Vorgehensbausteine sind die modularen Bausteine, aus denen dasV-Modell aufgebaut ist
Ein Vorgehensbausteinkapselt Rollen, Produkte und Aktivitätenist eine Einheit, die eigenständig verwendet werden kannist eine Einheit, die unabhängig veränder- und weiterentwickelbar ist
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Eine Projektdurchführungsstrategie definiert die Reihenfolge derim Projekt zu erreichenden ProjektfortschrittsstufenEin Entscheidungspunkt
definiert einen im Projektplan festzulegenden Zeitpunkt, an dem eine„Fortschrittsentscheidung“ (GO/NO-GO) getroffen wirdlegt eine Menge von Produkten fest, die zum Entscheidungspunkt fertiggestellt sein müssen, damit auf dieser Basis dieFortschrittsentscheidung getroffen werden kann
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)
Entscheidungspunkte für die Projekttypen:Systementwicklungsprojekt AuftraggeberSystementwicklungsprojekt AuftragnehmerSystementwicklungsprojekt Auftraggeber/AuftragnehmerEinführung und Pflege eines organisationsspezifischenVorgehensmodells
Individuen und Interaktionen wichtiger als Prozesse und WerkzeugeFunktionierende SW wichtiger als umfangreiche DokumentationZusammenarbeit mit Kunden wichtiger als VertragsverhandlungenReagieren auf Änderungen wichtiger als Verfolgung eines Plans
Extreme ProgrammingEvolutionäre EntwicklungFunktionalität als wesentliche „Stellschraube“Kombination verschiedener, sich ergänzender Praktiken, z.B.
Pair ProgrammingPlanning GameTest FirstKontinuierliche Code-Integration und Regressionstest
Skalierungsproblem (Größe, Kritikalität…)
1.5 (Vorgehensmodelle für die Softwareentwicklung)Kap. 1 (Einleitung und Grundlagen)