1.Kapitel EINFÜHRUNGUNDMOTIVATION Softwaretechnik Prof. Dr. Wolfgang Schramm Übersicht 1 1. EinführungundMoBvaBon 2. SoGwareprozesse 3. A n f o r d e r u n g s a n a l y s e u n d – SpezifikaBon 4. SoGwareentwurf 5. Entwurfsmuster 6. Programmierung 7. SoGware-Qualitätssicherung und Prüfung 8. KonfiguraBonsverwaltung 9. SoGware-Wartung Ziele 2 ¨ ¨ SiekennendenNutzenvon SoGware-Engineering. S i e ken n en gru n d l egen d e DefiniBonendesSE. Kapitelübersicht 3 1. MoBvaBon 2. Begriffe/DefiniBonen 3. Verantwortung Fragerunde 4 ¨ W e r h a t s c h o n S o G w a r e entwickelt? Fragerunde 5 ¨ Was heißt, eine SoGware ist gut? * nützlich und nutzbar * zuverlässig * flexibel * kostengünstig * rechtzeitig verfügbar • War Ihre Software gut? Fragerunde 6 ¨ Was sind typische SoGwareProjekt-Größen? (Anzahl Entwickler, Lines of Code) Diskussion 7 o Warum haben wir gerade über„Größe“geredet– hat Größe Einfluss auf die SoGware-Entwicklung? • Nennen Sie 5 Unterschiede zwischen der Entwicklung – alleine am PC ein kleines Programm zur Vereinsverwaltung – im Team eine neue Komponente für WORD 2014 Arto Teräs http://ajt.iki.fi/travel/debconf5/page2.html 8 SoGware-TechnikhilG, großeguteProgrammezuentwickeln SoftwareEngineering Projektmanagement Wissen und PraktikenWissen und Praktiken Allgemeines Management Projektmanagement Wissen und Praktiken Wissen und Praktiken BrauchenwirSoGwareEngineering?Ja…(1) 9 o CHAOSReport ¤ ¤ • JährlicherBerichtseit1994überdenErfolgvonIT-Projekten, herausgegebenvonderStandishGroup Es wurden ca. 100.000 IT-Projekte (vornehmlich in den USA) untersucht KategorisierungderProjekte ¤ ¤ ¤ Successful:ProjektwurdeinnerhalbdervorgegebenenZeitundBudget abgeschlossen. Projektergebnis ist im Einsatz und erfüllt alle Anforderungen. Challenged: Projekt ist abgeschlossen. Projektergebnis ist im Einsatz. Zeit,BudgetoderLeistungsindabernichtimvorgegebenenUmfang. Failed: Das Projekt wurde vorzeiBg abgebrochen oder das Projektergebniswurdenieeingesetzt. BrauchenwirSoGwareEngineering?Ja…(2a) 10 Chaos Report 1994 - 2012 100% 90% 16 27 26 28 80% 34 29 35 32 37 39 70% 60% 53 33 46 50% succeeded 49 51 40% 53 46 44 challenged 42 43 30% 20% 10% 31 40 28 23 15 18 19 24 21 18 0% 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 failed BrauchenwirSoGwareEngineering?Ja…(2b) 11 CHAOSReport2011-2105 BrauchenwirSoGwareEngineering?Ja…(2c) 12 ProjekterfolgabhängigvonderProjektgröße BrauchenwirSoGwareEngineering?Ja…(2d) 13 ProjekterfolgabhängigvomEntwicklungsprozess BrauchenwirSoGwareEngineering?Ja…(3) 15 o Haushalts-undKonsumelektronik ¤ ¤ o Einfachste Geräte wie Kaffeemaschinen, Waschmaschinen und KühlschränkebeinhaltenSoGwaresysteme ModerneGerätewieHandys,DVD-PlayerundDigitalkamerasbestehen zumgrößtenTeilausSoGware Automobilindustrie ¤ ¤ ¤ Betriebliche Abläufe, Verwaltung und ProdukBon wäre ohne SoGwaresystemenichtmehrmöglich IneinemFahrzeugsindheuteca.100Mikrocontrollerintegriert Mehr als die HälGe aller Fahrzeugpannen lassen sich auf SoGwareproblemezurückführen BrauchenwirSoGwareEngineering?Ja…(4) 16 o InformaBonssysteme ¤ ¤ ¤ Anwendungsbranchen:Finanzwesen,Medizinwesen,Verwaltung,... InformaBonssysteme haben inzwischen einen Durchdringungsgrad in derGeschäGsprozessunterstützungvon60%bis90% Die Abwicklung eines GeschäGsprozesses erfordert unter Umständen dasZusammenspielvonmehrals15Großanwendungen 17 Most of all, modern day systems are harder because we built all the easy ones years ago. Tom DeMarco BrauchenwirProjektmanagement? Projekte 18 Function points1 1 Function Point ~ 64 Zeilen C++ C. Jones, Assessment and control of Software risks, 1994 19 "We know why projects fail, we know how to prevent their failure - so why do they still fail?" Martin Cobb, 1995 WichBgste(Miss-)Erfolgsfaktoren 20 Ermittelt durch Befragung von Managern (CHAOS-Studie) ErfolgreicheProjekte • • • • • BeteiligungderzukünGigenNutzer Unterstützungdurchdas(obere)Management KlareAnforderungen Angemessene,ordnungsgemäßePlanung RealisBscheErwartungen Nachgebesserte/abgebrocheneProjekte • sieheoben–“anders”herum • TechnologischeDefizite • MangelndeRessourcen + - Fragerunde 21 ¨ Waskanndennschonpassieren, w e n n m a l e i n p a a r B i t s durcheinander-kommen? HerausforderungendesSoGwareEngineering 22 1. Heterogenität ¤ ¤ Verteiltheit, heterogene HW, heterogene OS, heterogene Programmiersprachen,altevs.neueSW-Systeme KostengünsBge IntegraBon/Weiterentwicklung bei Sicherstellung der GeschäGsprozesse 2. Entwicklungsgeschwindigkeit ¤ ¤ HoheInnovaBonsgeschwindigkeit SchnellereSoGware-EntwicklungbeigleichbleibenderQualität 3. Vertrauen ¤ ¤ SWistinallenLebensbereichen(Web,eingebeset) NachweisbarsichereSysteme 23 Es gibt eine Grenze, wie viel ein Mensch zu einer gegebenen Zeit verstehen kann. Inhalt 24 1. MoBvaBon 2. Begriffe/DefiniBonen 3. Verantwortung SoGware-Engineering:Historisches(1) 25 o 1940–1950 Computer werden nur für die Ausführung einzelner Programmebenutzt. ¤ ¤ ¤ o EntwicklungdeselektronischenRechners KeineBetriebssysteme→ProgrammewerdenvonLochkartengeladen TypischeAnwendung:technisch-wissenschaGlicheBerechnungen 1950–1960 Computer werden nur für die gleichzeiBge Ausführung mehrererAnwendungsprogrammebenutzt. ¤ ¤ SingleUserBetriebssysteme HöhereProgrammiersprachen(u.a.Fortran,Cobol) SoGware-Engineering:Historisches(2) 26 o 1960–1970 Computer werden in großem Umfang in allen möglichen Bereicheneingesetzt. ¤ ¤ ¤ o LeistungsfähigereundpreiswertereRechner MulBUserBetriebssysteme DieAnwendungenwerdenzahlreicher,komplexer,kriBscher 1968 NATO-KonferenzinGarmisch-Partenkirchen ¤ ¤ QualitätsproblemeerkanntàSoGware-Krise Lösung àSoGware-Engineering DefiniBonSoGware 27 Computer programs, procedures, and possibly associated documentaBon and data pertaining to the operaBon of a computersystem. IEEE Standard 620.12 – 1990: Glossary of Software Engineering Terminology DefiniBonSoGwareProduct 28 Setofcomputerprograms,procedures,andpossiblyassociated documentaBonanddata ISO/IEC 12207 (2008) Systems and software engineering – Software life cycle processes DefiniBonEngineering 29 The applicaBon of a systemaBc, disciplined, quanBfiable approach to structures, machines, products, systems, or processes. IEEE Standard 620.12 – 1990: Glossary of Software Engineering Terminology DefiniBonSoGware-Engineering(1) 30 SoGware engineering is the establishment and use of sound engineeringprinciplesinordertoobtaineconomicallysoGware thatisreliableandworksefficientlyonrealmachines P. Naur and B. Randall (eds.), Software Engineering: A Report on a Conference Sponsored by the NATO Science Committee. NATO 1969 Diskussion 31 ¨ „Engineering“, „SoGware“… wasbedeutet *systemaBc, *disciplined, *QuanBfiable approach inderSoGwareentwicklung? DefiniBonSoGware-Engineering(2) 32 Eine technische Disziplin, die sich mit allen Aspekten der SoGwareherstellung befasst, von den frühen Phasen der SystemspezifikaBonbishinzurWartungdesSystems,nachdem seinBetriebaufgenommenwurde. [Sommerville 2004] Technische Disziplin Suche nach Lösungen (auch, wenn keine theoretischen Grundlagen existieren) innerhalb organisatorischer und finanzieller Beschränkungen Alle Aspekte der Softwareherstellung Nicht nur technische Aspekte, sondern auch Projektverwaltung, Entwicklung neuer Theorien, Methoden, Werkzeuge etc. DefiniBonSoGware-Engineering(3) 33 1. TheapplicaBonofa ¤ ¤ ¤ systemaBc, disciplined, quanBfiable IEEE Standard 620.12 – 1990: Glossary of Software Engineering Terminology approachtothe ¤ ¤ ¤ development, operaBon,and Maintenance of soGware; that is, the applicaBon of engineering tosoGware. 2. Thestudyofapproachesasin(1) DefiniBonProjekt 34 Vorhaben, das im Wesentlichen durch Einmaligkeit der BedingungeninihrerGesamtheitgekennzeichnetist,wiez.B. ¤ ¤ ¤ ¤ Zielvorgabe Zeitliche,finanzielleoderandereBegrenzungen AbgrenzungengegenüberanderenVorhaben ProjektspezifischeOrganisaBon DIN 69901 Atemporaryendeavorundertakentocreateauniqueproduct, service,orresult. PMBOK DefiniBonProjektmanagement 35 GesamtheitvonFührungsaufgaben,-organisaBon,-techniken und-miselfürdieAbwicklungeinesProjektes. DIN 69901 The applicaBon of knowledge, skills, tools, and techniques to projectacBviBestoachievetheprojectrequirements PMBOK Inhalt 36 1. MoBvaBon 2. Begriffe/DefiniBonen 3. Verantwortung DerBerufdesSoGware-Entwicklers 37 o SoGwareentwicklerentwickelnProgramme ¤ ¤ o o o Programmesollen… Fehlerpassieren... SoGwareentwickler arbeiten anhand definierter Prozesse an Produkten SoGwareentwicklerbraucheneine(formale)Ausbildung SoGwareentwicklerfühlensichverantwortlich Fragerunde 38 ¨ ¨ MachenSieFehler? WiegehenSiemitFehlernum? BeruflicheundethischeVerantwortung 39 1. Gesetze ¤ legalerRahmen 2. ProfessionelleVerantwortung ¤ Vertraulichkeit n ¤ Kompetenz n ¤ „ichmachenur,wasichkann“ SchutzdesgeisBgenEigentums n ¤ gegenüberArbeitgeberoderKunden Arbeitgeber/-nehmer,AuGraggeber/-nehmer Computermissbrauch n n Surfen/Spielen Virenetc. Ethik 40 o Ethikbefasstsichmit ¤ ¤ ¤ o denbedachtenHandlungenund derenFolgen(Menschen,Umwelt,…) ausderSichteinesverantwortlichenIndividuums Ethikumfasst: ¤ ¤ ¤ ¤ ¤ ¤ jemandistverantwortlich füretwas gegenüberjemandem voreinerInstanz inBezugaufKriterien imRahmeneines besBmmtenKontextes Personen,KorporaBonenetc. Folgen Betroffene SankBons-und/oder Urteilsinstanzen Normen,Werte Verantwortungs-und/oder Handlungsbereiche IEEE/ACMEthischeRegeln(1) 41 EthischeRegelnundprofessionellesVerhalten desSoGwareEngineering ©1999IEEE/ACM o Öffentlichkeit ¤ o SoGwareentwicklersolleninÜbereinsBmmungmitdem öffentlichenInteressehandeln KundeundArbeitgeber ¤ SoGwareentwickler sollen auf eine Weise handeln, die im Interesse ihrerKundenundihresArbeitgebersistundsichmitdemöffentlichen Interessedeckt IEEE/ACMEthischeRegeln(2) 42 o Produkt ¤ o Beurteilung ¤ o SoGwareentwicklersollensicherstellen,dassihreProdukteunddamit zusammenhängende ModifikaBonen den höchstmöglichen professionellenStandardsentsprechen SoGwareentwickler sollen bei der Beurteilung eines Sachverhalts IntegritätundUnabhängigkeitwahren Management ¤ Für das SoGware Engineering verantwortliche Manager und Projektleiter sollen sich bei ihrer TäBgkeit ethischen Grundsätzen verpflichtetfühlenundindiesemSinnehandeln IEEE/ACMEthischeRegeln(3) 43 o Beruf ¤ o Kollegen ¤ o SoGwareentwickler sollen die Integrität und den Ruf des Berufs in ÜbereinsBmmungmitdemöffentlichenInteressefördern SoGwareentwickler sollen sich ihren Kollegen gegenüber fair und hilfsbereitverhalten Selbst ¤ SoGwareentwickler sollen sich einem lebenslangen Lernprozess in Bezug auf ihren Beruf unterwerfen und anderen eine ethische AusübungdesBerufsvorleben Fragerunde 44 ¨ ¨ Die Regeln helfen in vielen SituaBonen. In welchen SituaBonen führen siezuKonflikten? Diskussion 45 Lesen Sie die beiden ArBkel zur VW-Abgas-Affäre. 1. WasdenkenSiealsKonsument, alsumweltbewussterBürger? 2. Wie würden Sie sich verhalten, wenn Sie zu den „vielen Mitarbeitern, die davon wussten“ gehörenwürden? 3. Wie würden Sie sich als Mitglied des „kleinen, eingeweihtenKreises“verhalten? ÜberlegenSiefürsichalleine 47 Sind Sie für „selbs|ahrende Autos“ auf deutschen Straßen in naherZukunG? Fallsja,wassindfürSiediegroßen Herausforderungen auf dem Weg dorthin? Falls nein, was spricht für Sie dagegen? Notieren Sie Ihre Gedanken! Diskussion 48 ...und wenn bremsen nicht mehr möglichist? hsp://moralmachine.mit.edu/ WieentscheidenSie? Schauen Sie sich die SituaBon genauan! DiskuBerenSiedieEntscheidungin derGruppe! Diskussion 49 Lesen Sie die drei ArBkel zum „selbs|ahrenden Auto“ (teilen Sie die ArBkel in der Gruppe auf und stellenSiesiekurzvor) 1. Dürfen selbs|ahrende Autos EntscheidungenüberLebenund Tod treffen? Ist diese Frage für Sierelevant? 2. Wie möchten Sie, dass Ihr selbs|ahrendes Auto entscheidet? 3. Würden Sie gerne an der SoGware für selbs|ahrende Autosmitarbeiten? Bereiten Sie einen 2-MinVortrag mit Ihren Ergebnissen (Tafel oder Flipchart) vor ÜberlegenSiefürsichalleine 50 Sind Sie für „selbs|ahrende Autos“ auf deutschen Straßen in naherZukunG? Fallsja,wassindfürSiediegroßen Herausforderungen auf dem Weg dorthin? Falls nein, was spricht für Sie dagegen? Haben Sie neue Erkenntnisse gewonnen? Sind Sie noch der gleichen Meinung? DemokraBscheAlgorithmen 51 AlgorithmenalsStraßenschilderimNetz o Algorithmen besBmmen unsere Wege im Internet und unterstützenunserSurfverhaltenimNetz–dasistvielenNutzern bewusst. o DieProzessehelfenunsEntscheidungenindenunüberschaubaren Weiten des Internet zu treffen, sie besBmmen Richtungen, geben Vorschläge. o Für Nutzer verspricht das viele Vorteile, denn oG wird uns genau dasvorgeschlagen,waswirsowiesoschongesuchthasen. o Die Möglichkeiten algorithmischer Entscheidungsfindung sind grenzenlos. ¤ o Von selbs|ahrenden Autos über interne|ähige Kühlschränke bis SmartHomes, auch Unternehmen greifen immer häufiger auf Algorithmen zurück Im Umkehrschluss heißt das aber auch: Je weniger wir eigene Entscheidungen treffen müssen, desto mehr gewinnt der AlgorithmusdieOberhandinunseremHandeln. DemokraBscheAlgorithmen 52 VerkehrsregelnauchfürAlgorithmen o DerEinflussden AlgorithmenaufunsereGesellschaGhabenwirdimmer deutlicher. o Besondersdort,woRegierungenunddieöffentlicheHandsichebenfalls diese Prozesse zu nutzen machen wollen, sollten wir aber nicht unreflekBertzuschauen. o DieIniBaBveAlgorithmWatchsiehthierdeutlicheGefahren. o Das Forscherteam setzt sich interdisziplinär aus JournalistInnen, SozialwissenschaGlerInnenundInformaBkerInnenzusammen. o ZielvonAlgorithmWatchistes,NutzerInnendafürzusensibilisieren,dass die vermeintlich objekBven, technischen Prozesse immer menschengemachtsindunddamitbesBmmtenWerturteilenfolgen. o Aus diesem Grund nimmt das Team gesellschaGlich relevante Technologien unter die Lupe und zeigt uns, wie wichBg demokraBsche Kontrolleist. o Welchen gesellschaGlichen Einfluss können Algorithmen auf unsere poliBscheEntscheidungsfindunghaben? o Werkontrolliertsie,wiewerdensieentwickelt? Quelle:hsp://poliBk-digital.de/news/wenn-algorithmen-zu-entscheidern-werden-algorithmwatch-149194