Home

Software Engineering

1. Abbildung g 4 1 Der Euklidische Algorithmus in PDP 8 Assembler implementiert von Brian Shelburn http http www4 wittenberg edu academics mathcomp bjsdir PDP8Labs zip etwas komplizierteren Algorithmen fast ausschlie lich in Hochsprachen die zumeist an das Englische angelehnt sind Abb 4 2 Dem Computer ist es egal wie ein Programm ge public static long euclid long a long b long tmp while n gt 0 tmp m m n n tmp m return m Abbildung 4 2 Der Euklidische Algorithmus in Java schrieben ist Doch Programmierer m ssen sie lesen und verstehen um sie zu schreiben oder zu modifizieren Fast jedes eingesetzte Programm wird w hrend seiner Lebenszeit mo difiziert Modifikation von Software ist nicht die Ausnahme sondern die Regel Einer der wichtigsten Programmiergrunds tze lautet damit Programme m ssen m glichst leicht lesbar verstehbar und modifizierbar sein Ein Mittel dazu ist das Prinzip der Modularit t Computerprogramme sollen in kleine und m glichst unabh ngige Teile zerlegt werden Jedes Modul hat seine spezifischen Aufgaben Dadurch werden die drei obigen Ziele simultan erreicht Denken Sie an ein gutes Benutz handbuch eines technischen Produkts Es ist in separate Themen unterteilt die sich in ihren Funktionalit ten unterscheiden Bei dem Benutzhandbuch f r ein Auto werden die Instru mente und Kontrollanzeigen erkl rt in anderen Abschnitten wird angegeb
2. Abfragen lt Software Ausgaben Schnittstellendaten Abbildung 6 3 Die f nf Kategorien der Datenelemente zur Ermittlung der Funktionspunkte e Datenbest nde sind interne Datenspeicher des Systems also Datenbanken oder Datei en e Eingabedaten sind jene Daten oder Kontrolldaten die in das System eingegeben wer den und von einem elementaren Prozess verarbeitet werden Sie dienen in der Regel zur Pflege der Datenbest nde e Ausgabedaten sind Daten die von einem elementaren Prozess nach au en gesendet werden also z B zur Ausgabe auf den Bildschirm Diese Daten m ssen zuvor entwe der durch eine mathematische Funktion errechnet oder durch anderweitige Prozesslo gik aus den Datenbest nden abgeleitet worden sein e Dagegen sind Abfragen sehr einfache elementare Funktionen die Daten aus den Da tenbest nden ausgeben ohne diese zuvor verarbeitet zu haben e Schnittstellendaten sind Daten auf die durch das zu entwickelnde System zugegriffen wird Diese Daten werden aber nicht in diesem System gepflegt sondern durch ein Fremdsystem Wurden die Function Points f r diese Daten bereits in dem Fremdsys tem gez hlt so k nnen diese bernommen werden Die Funktionspunkte werden ermittelt indem man alle Transaktionen Funktionen und so alle Datenelemente des Softwaresystems ermittelt Anschlie end ordnet man diesen Da tenelementen Komplexit tsgrade einfach mittel komplex gem der folgenden Tabel
3. 4 1 3 Erstelle so schnell wie m glich einen Prototyp Eaei aa em Ne aa ai RR 4 1 5 Speichere numerische Daten in ASCI Dateien 4 1 6 Nutze die Hebelwirkung von Software zu deinem Vorteil 4 1 7 Vermeide Benutzeroberfl chen die den Benutzer gefangen halten 4 2 Programmierleits tze nach OpenSource 4 3 Modularit t und Schnittstellen 23 Pius sida a 4 4 Code Konventionen 2 2 Hmm nn Kollaborative Softwareentwicklung 5 1 Grunds tzliche Problematiken 2 2 2 2 Com nn 5 1 2 Branching Trunk und Fork ii A II 37 UN EA A E A a a a 38 5 3 1 __Revisionenl 2 222 22 Cm oo rennen 38 39 39 40 6 1 Lines f Code LOC ar do AAA 40 42 43 43 43 ea a a ro do a a a A 43 Pa ea a da da da a a 44 Ed e a lr o de e di ae de re o do o da e a e A 44 A AAA 44 cdo Becker Be rs dei a a a a a ee A 44 AE AAA a O ia o See Bean See 44 ee ta e De e Bee a ee A 45 7 Softwarequalit t 48 E ee a a a 48 7 2 Kosten und Nutzen von Softwarequalit t o o 49 AAA 50 73 1 Fehler aaa 234 da dd dei dedo dedo de A 50 ide o 51 Literaturverzeichnis 53 111 Einleitung Die Erstellung von Software ist kein einfaches Gesch ft Im Gegensatz zu den meisten mate riellen menschlichen Produkten wie Werkzeugen Maschinen oder Fahrzeugen zeichnet sich Software durch hohe Komplexit t und Flexibilit t aus Freilich ist es genau diese Flexib
4. e Implementierung In diesem Prozess wird der Entwurf in spezifische Programme um gesetzt Jedes Modul wird separat f r sich implementiert am Ende werden die Module zu einem vollst ndigen System zusammen gef gt Dieser Teilschritt heift Integration e Funktionspr fung Verifikation Bei diesem Prozess wird verifiziert ob jedes einzel ne Modul Modultest und das gesamte System Integrationstest die Spezifikationen erf llt Die Verifikation erfordert eine formale Spezifikation gegen ber der das Programm gepr ft werden soll Allerdings ist die bersetzung der tats chlichen Anforderungen und Bed rfnisse in eine formale Spezifikation ein hartes Problem und mindestens so fehleranf llig wie die Programmierung e Inbetriebnahme Installation Die Inbetriebnahme umfasst alle T tigkeiten die die Installation der Software betreffen ggf Beta Tests oder L sen von Migrationsproble men bei der Abl sung von Altsystemen legacy systems aber auch Schulungen oder Unterst tzung der Anwender e Wartung Anders als mechanische Systeme nutzen Softwaresysteme nicht mit der Zeit ab Ein Programm muss nicht nach 300 000 km oder 10 Jahren einer berholung un terzogen werden es wird auf ewig so funktionieren wie am ersten Tag Das ist das Problem Damit Software n tzlich bleibt muss sie modifiziert werden Modifikationen k nnen n tig werden weil die Hardware ausgetauscht wird weil gesetzliche Bestim mungen sich ge ndert haben die Anfor
5. festgelegten Erfordernissen ist das schon schwer genug und gelingt nur mit gen gender Sorgfalt bei Analyse und Entwurf Ein weit gr eres Problem sind die voraus gesetzten Erfordernisse hier gibt es die schwerwiegendsten Missverst ndnisse Denn was der eine stillschweigend voraussetzt muss der andere noch lange nicht wissen Wer sich bei spielsweise eine Uhr implementieren l sst wird kaum explizit fordern dass sie nach 23 59 Uhr wieder mit 0 00 Uhr beginnt D h ein gewisses Grundverst ndnis muss man voraus setzen Aber wo endet es genau Vermeintliche Selbstverst ndlichkeiten sind die h ufigsten Fallen bei der Anforderungsermittlung Umgekehrt beziehen sich viele Anforderungen auf die Qualit t von Software und Syste men Bei Anforderungen denkt man zumeist an die funktionalen Anforderungen an die Soft ware die beschreiben welche Funktionen sie haben soll Qualit tsanforderungen aber die festlegen wie und in welcher Qualit t die Software laufen soll sind abder ebenso wichtig auf die Architektur eines Systems haben sie sogar oft gr eren Einfluss als funktionale An 48 forderungen Qualit tsanforderungen sind aus Qualit tszielen aufgebaut die sich ihrerseits auf angestrebte Qualit tsmerkmale beziehen Qualit tsmerkmale oder Qualit tsaspekte sind einzelne Eigen schaften einer Einheit anhand derer die Qualit t beschrieben und beurteilt wird y Ein Qualit tsziel ist ein angestrebtes Merk
6. 3 Definition Was ist nun genau unter dem Begriff Software Engineering zu verstehen Dazu m ssen wir zun chst wissen Was ist Software Software ist ein vielf ltiges Produkt Es setzt sich zu sammen aus verschiedenen Teilprodukten Analysemodell Architekturmodell Programme Code ferner geh ren dazu Dokumentationen Benutzerhandbuch Hilfesystem Testdaten Review Ergebnisse usw Software Engineering oder Softwaretechnik besch ftigt sich mit der systematischen Erstellung von Software Es ist die zielorientierte Bereitstellung und systemati sche Verwendung von Prinzipien Methoden und Werkzeugen f r die arbeitsteilige ingenieurm ige Entwicklung und Anwendung von umfangreichen Softwaresystemen 1 S 36 Etwas detallier ter formuliert untersucht und entwickelt das Software Engineering Prinzipien Methoden Techniken und Werkzeuge um Software e mit einem festgelegten Funktionsumfang e in ausreichender Qualit t e innerhalb eines gegebenen Budgetrahmens e zum geplanten Termin zu erstellen Software Engineering behandelt also nicht nur die eigentliche Entwicklung von Software sondern auch Fragen der Qualit tssicherung von Software und des Projektmana gements Nach dem offiziellen Guide to the Software Engineering Body of Knowledge swebok Hand buch des gesammelten Wissens zum Software Engineering kurz SWEBOK der IEEE Com puter Society umfasst das Software Engineering die folgenden zehn Teildisziplinen e Anfor
7. Administrator durchf hren blicherweise werden in einem Projekt die Basisverzeichnisse Trunk Branches und Tags angelegt Ein Trunk enth lt dabei den Letztstand des Projekts in Branches werden weitere Unterverzeichnisse mit alternativen Entwicklungspfaden verwaltet und in Tags eine Kopie von Trunk oder einem der Branches als Unterverzeichnis angelegt Zur besseren bersicht werden je nach Projektanforderungen Tags und Branches noch in weitere Unterverzeichnisse unterteilt Durch das Fehlen einer festgelegten Semantik f r Tags ist die Angabe der Revisionsnum mer als Referenz beispielsweise beim Bug Iracking oder in der Dokumentation unabding bar Da Dateien in Subversion auch versionskontrolliert umbenannt werden k nnen kann die Projektstruktur jederzeit ge nderten Anforderungen angepasst werden 5 3 3 Der Merge Prozess in SVN Fe Gx Workspace Client 1 checkout eonna checkout switch commit merge Branch gt A A Trunk gt Repository Abbildung 5 5 Der Merge Prozess in SVN Hier arbeitet der Entwickler an einem Branch Revision 2 und 3 um den Branch an Revision 3 mit dem Trunk zusammenzuf hren muss er zun chst zum Trunk wechseln per checkout oder k rzer ber switch wodurch in seinem Workspace seine Branch Version berschrieben wird erst durch den merge Befehl stellt er dort die Merge Version 1 amp 3 her die er dann per commit in den Trunk im Repos
8. Terminologie von XP Praktiken genannt bis zum u ersten treibt Beispielsweise bef rwortet sie h ufige und automatische Tests Auch die evolution re Entwicklung wird extrem ausgef hrt Ers tens findet die Systemintegration h ufig statt mindestens einmal am Tag so dass stets ein voll arbeitsf higes System verf gbar ist auch wenn es in den Zwischenversionen nicht alle Anforderungen erf llt dadurch kann man jedoch das System zu jeder Zeit aktuell testen Zweitens basiert die Entwicklung auf kurzen Zyklen etwa drei Wochen nach Art des Spi ralmodells Abb 2 7 Drittens gibt es alle paar Monate Kundenversionen Releases was bedeutet dass der Kunde die ganze Zeit in den Prozess eingebunden sein muss und nicht nur in der Anfangsphase wie im Wasserfallmodell ein vor Ort verf gbarer Kundenver treter geh rt somit zu den grundlegeneden Forderungen der extremen Programmierung Viertens wird das agile Prinzip der Paarprogrammierung verlangt Neben der Einfachheit sind effektive Kommunikation und sofortiges Feedback Grund prinzipien des XP Um effektive Kommunikation zu erm glichen sitzen alle Entwickler in einem Raum und repr sentative Anwender sowie Fachexperten sind eng in die Entwick lung eingebunden statt mit formalen Dokumenten erfolgt die Kommunikation m glichst in direkten Gespr chen und durch den Quelltext Inline Dokumentation Das sofortige Feed back wird erreicht durch konsequente Paarprogrammierung auf der Codierungs
9. beitszeiten zu achten ist berstunden zeugen von schlechtem Projektmanagement 24 2 4 Flexibles Rahmenmodell V Modell XT Das V Modell XT ist ein sehr umfangreiches Vorgehensmodell das in seiner aktuellen Ver sion 1 3 von 2009 das urspr ngliche V Modell um iterativ inkremnetelle Vorgehensweisen und agile Elemente s u wesentlich erweitert Es ist in 1990er Jahren urspr nglich f r die Bundeswehr entwicjkelt worden wurde sp ter f r s mtliche Bundesbeh rden verbindlich und findet mittlerweile auch in der Industrie weite Verbreitung Wesentliche Elemente des V Modells XT sind die Vorgehensbausteine die zusammengeh rige Rollen Produkte und Aktivit ten kapseln und aus denen das konkrete Vorgehensmo dell eines Projekts zusammengestellt wird Tailoring f Ein Vorgehensbaustein deckt ei ne konkrete Aufgabenstellung ab die im Rahmen eines V Modell Projektes auftreten kann Festgelegt werden dabei die innerhalb dieser Aufgabenstellung zu erarbeitenden Produk te die Aktivit ten durch welche die einzelnen Produkte erstellt werden sowie die an den einzelnen Produkten mitwirkenden Rollen Die einzelnen Vorgehensbausteine sind dabei jeweils in sich abgeschlossen Ein Produkt bezeichnet ein allgemeines Arbeitsergebnis oder Erzeugnis und kann beispielsweise das zu erstellende System ein Dokument Pr fprotokoll oder ein Software Modul sein Eine Aktivit ten bearbeitet oder ver ndert Produkte Eine Rolle ist die Beschreibung eine
10. gebracht wurden Dies ist an sich aber kein Problem denn die F e werden in einer H he von etwa 1500 Metern ausge fahren w hrend die Software die Maschinen nicht ausschaltet solange die durch den Radar gemessene H he des Landers ber der Oberfl che mehr als 40 Meter betr gt Leider wurde nur das beim Ausfahren der Landef e registrierte unechte Signal nicht gel scht so dass die Maschinen abgeschaltet wurden als der Lander eine H he von 40 Metern erreichte und er somit abst rzte und am Boden zerschellte Der Bericht f hrte an Dieses Verhalten war bekannt und die Flugsoftware sollte diese Ereignisse ignorie ren jedoch beschrieben die Anforderungen diese Erignisse nicht spezifisch so dass die Software Entwickler nicht daf r verantwortlich gemacht werden k nnen Der Schaden belief sich auf etwa 230 Millionen US Explosion der Ariane 5 Etwa 40 Sekunden nach dem Start zu ihrem Jungfernflug am 4 Juni 1996 nahm die Rakete Ariane 5 der ESA einen so abrupten Kurswechsel vor dass sie zerbrach und explodierte Der Untersuchungsausschuss stellte fest dass die in Tei len von der Ariane 4 bernommene Software nicht mehr den n tigen Anforderungen entsprach Die Ariane 5 beschleunigt schneller als die Ariane 4 Dies f hrte zu einem berlauf einer Variablen des Lenksystems n mlich bei der Umwandlung einer 64 Bit Gleitkommazahl f r die horizontale Geschwindigkeit in eine vorzeichenbehaftete 16 Bit Ganzzahl Das Ergebnis
11. ist Jede der Phasen kann zeitlich mit Terminen f r ihren Meilen stein also ihre Beendigung versehen werden F r das Projektmanagement wird es damit m glich durch die zeitliche Planung und Ressourcenzuteilungen zu den einzelnen Phasen Kosten und Termine abzusch tzen Insgesamt ist das Wasserfallmodell in seiner strikten Auslegung ein dokumentorientiertes Vorgehensmodell denn zu jeder Entwicklungsphase gibt es eine klare Definition dar ber 13 welche Produkte oder Ergebnisdokumente nach ihrem Abschluss verf gbar sein m ssen Sol che Ergebnisdokumente k nnen Programme oder Dokumentationen sein und dienen als Kontrollpunkte des Gesamtprozesses Die Projektleitung und ggf der Kunde k nnen da mit den Fortschritt des Prozesses anhand der Ergebnisdokumente verfolgen Das Modell hat neben diesen hinsichtlich des Projektmanagements positiven Eigenschaf ten aber auch einen gravierenden Nachteil Damit eine Phase begonnen werden kann muss die vorherige Phase vollst ndig erledigt sein So muss der Anforderungskatalog komplett erstellt sein bevor man mit dem Entwurf beginnen kann Umgekehrt ist damit der An forderungskatalog endg ltig eingefroren wenn die Entwurfsphase gestartet ist und kann nicht mehr ver ndert werden Oft wird das Problem jedoch in den ersten Phasen nur va ge verstanden oder wesentliche Detailprobleme oder auch Denkfehler werden erst in den sp teren Phasen entdeckt W hrend der Entwurfsphase oder der Implementie
12. ist ein gut strukturiertes und dennoch felxibles Vorgehensmodell Das gesamte Team tr gt die gemeinsame Verantwortung f r das Endprodukt Durch die t glichen Treffen die Daily Scrums bewirken eine gute Abstimmung und eine hohe Projekttransparenz innerhalb 16 des Teams und f rdern damit eine Fokussierung auf das Sprintziel Durch die verh ltnis m ig kurze Sprintdauer von etwa 30 Tagen mit jeweils mess und berpr fbarem Ergebnis ergibt sich eine hohe Planungssicherheit 2 2 Softwareentwicklung als Prozess Zu den komplexesten und dennoch im Verh ltnis zu ihrer Komplexit t am besten funk tionierenden Softwaresystemen geh ren die modernen Betriebssysteme oder gro e Open Source Projekte wie Apache Firefox oder Thunderbird Die Entwicklung dieser Systeme wird jedoch an sich nicht als zu einem Zeitpunkt zu beendendes Projekt verstanden son dern radikal anders als Prozess der in verschiedenen Versionsstufen evolution r und offen verl uft 2 2 1 Das Spiralmodell Das Spiralmodell wurde von Boehm eingef hrt 3 Grunds tzlich erm glicht es auch ein Vorgehen mit offenem Ende Es wird in der Literatur nicht immer einheitlich interpretiert hier verwenden wir die Darstellung von Balzert 1 S 130 Ein Phasenzyklus wird hierbei Kosten A Risikoanalyse Zielidentifikation Prototyping Fanm des n chsten Zyklus Entwicklung und Verifikation Produkt Pilot Abbildung 2 5 Das Spiralmodell mehrfach durchgef hrt
13. k nnen neue Stories hinzukommen oder bestehende verfeinert werden Wichtig ist auch die Testfallspezifikation vor der Implementierung so kann man schon w hrend der Codierung automatisiert erste Funktionstests durchf hren Die eXtreme Programmierung setzt einige soziale Voraussetzungen an die Entwickler und Kunden e Alle Entwickler sollten ber eine gute und breite Qualifikation und hohe soziale Kom petenz verf gen da sie laufend in anderen Paaren und f r andere Aktivit ten einge setzt werden Paare aus einem erfahrenen Mitarbeiter und einem Anf nger sollten nur zu Schulungs und Einarbeitungszwecken gebildet werden e Alle am Projekt Beteiligten Management Teammitglieder Auftraggeber und Anwen der m ssen die XP Praktiken akzeptieren Insbesondere muss also der Auftraggeber bereit und in der Lage sein einen qualifizierten Mitarbeiter als Anwendervertreter f r das Projektteam abzustellen Aufgrund der hohen Dynamik und den sich oft erst im Projekt ergebenden Systemanforderungen ist es problematisch f r das Projekt ver tragliche Vereinbarungen zu treffen die allen Beteiligten Planungssicherheit geben e XP erfordert hohe intensive Kommunikation und funktioniert am besten wenn die Entwickler an einem Ort konzentriert sind und die gleichen Arbeitszeiten haben Zu dem stellt die arbeitsteilige Paarprogrammierung hohe Anforderungen an die Kon zentration und Leistungsf higkeit der Entwickler so dass unbedingt auf geregelte Ar
14. top level Eclipse Technology Project It has two goals e To provide an extensible framework and exemplary tools for software process enginee ring method and process authoring library management configuring and publishing a process e To provide exemplary and extensible process content for a range of software deve lopment and management processes supporting iterative agile and incremental de velopment and applicable to a broad set of development platforms and applications For instance EPF provides the OpenUP Basic an agile software development process optimized for small projects Teil des EPF ist der Open Unified Process OpenUP ein Open Source Software Entwicklungs prozess der von der Eclipse Foundation entwickelt wird OpenUP orientiert sich an Best Practices der Softwareentwicklung und h lt die grundlegenden Eigenschaften des Rational Unified Process RUP ein also e iterative Softwareentwicklung iterative and incremental development e Anwendungsf lle use cases e szenarienbasierte Entwicklung e Risikomanagement und architekturzentriertes Vorgehen 2 2 5 Open Source das Basarmodell Das Basarmodell Bazaar model der Softwareentwicklung verzichtet bewusst auf klar unter scheidbaren Rollen von Anwendern und Entwicklern Seinen Namen 7 bekam es in Ab grenzung zu den klassischen Vorgehensmodellen nach der Kathedral Bauweise mit zen tralisierter Planung und m glichst wenigen hochspezialisierten Progra
15. war ein Programmabsturz des Lenksystems was dazu f hrte dass die Navigationsanlage nur noch Statusdaten an den Navigationscompu ter sandte die dieser als echte Fluglage interpretierte die betr chtlich vom geplanten Kurs abwich und so die Schubd sen der Booster bis zum Anschlag schwenken lie Dadurch begann die Rakete auseinanderzubrechen Gl cklicherweise kamen keine Menschen ums Leben doch der materielle Schaden be lief sich auf etwa 500 Millionen US Dollar womit der Fehlstart einen der teuersten Computerfehler der Geschichte darstellt Y2K Erstmals traten 1998 Fehlerf lle auf bei denen Computer g ltige Kreditkarten als abgelaufen ablehnten Hintergrund war dass die Jahreszahlen in den Programmen nur zweistellig abgespeichert wurden so dass das Ablaufdatum im Jahr 2000 f r das Jahr 1900 gehalten wurde Tats chlich wurde Ende der 1990er Jahre vermutet dass der gr te Teil der damals verwendeten Computerprogramme in allen Bereichen und Branchen an diesem Jahr 2000 Problem Y2K year 2 kilo litten Es gab im Vorfeld Bef rchtungen dass nach dem Jahreswechsel 1999 2000 Sicherheitssyteme von Atom kraftwerken oder Navigationssysteme von Flugzeugen versagen w rden Zinsen und Geb hren falsch berechnet werden ja dass sogar das ffentliche Leben in gro en Teilen zusammenbrechen w rde Am Ende passierte nichts Obschon es damals auch iro nische Stimmen gab die das entstandene Problembewusstsein als bertriebene P
16. wird 4 1 7 Vermeide Benutzeroberfl chen die den Benutzer gefangen halten Eine CUI Captive User Interface ist eine Applikation die eine Interaktion mit dem Benut zer au erhalb des h chsten Befehlsinterpreters erzwingt Ist die Anwendung einmal gest artet gehen alle Eingaben des Benutzers an sie und nicht an den Befehlsinterpreter bis das Programm wieder beendet wird CUls neigen zu gro ist sch n im Widerspruch zu Leitsatz 1 Da der Benutzer in der Oberfl che gefangen ist hat er keinen direkten Zugriff auf andere Systemfunktionen wes wegen zunehmend Druck entsteht diese innerhalb der Applikation zu duplizieren 30 Programme mit CUI sind schwer mit anderen Programmen zu kombinieren weil sie auf der Annahme basieren der Benutzer sei ein Mensch Die St rke von Unix liegt aber darin wie Programme miteinander arbeiten Programme mit CUI lassen sich gar nicht oder nur sehr schwer in Skripte einbinden Abl ufe nicht automatisieren sie ziehen keinen Vorteil aus der Software Hebelwirkung Da sie nicht mit anderen Werkzeugen kombiniert werden k nnen m ssen deren Funktionen mit eingebaut werden In einem Teufelskreis gefangen w chst das Programm zu einem immer gr eren und schwerf lligeren Monolith CUls skalieren nicht Ein Programm das z B der Reihe nach alle notwendigen Angaben abfragt die notwendig sind um einen neuen Benutzerzugang auf einem System anzule gen oder ein entsprechendes Men anbietet mag a
17. wobei aber pro Phase stets dieselben 4 bzw 41 Schritte durchge f hrt werden Abb 2 5 1 Schritt Zielidentifikation e Identifikation der Ziele des n chsten Zyklus Leistung Funktionalit t Anpassbarkeit ee e Erkennen alternativer M glichkeiten zur Phasenrealisierung Entwurf A Entwurf B Make Buy e zu beachtende Randbedingungen Kosten Zeit Schnittstellen 2 Schritt Risikoanalyse 17 e Evaluierung der Alternativen unter Ber cksichtigung der Ziele und Randbedingun gen e Entwicklung kosteneffizienter Strategien zur Risiko berwindung z B durch Prototy pen Simulationen Benutzerbefragungen usw 3 Schritt Entwicklung und Verifikation e Entwurf Implementierung und Tests 4 Schritt Planung des n chsten Zyklus e Planung des n chsten Zyklus unter Einbeziehung der ben tigten Ressourcen ggf Aufteilung des Produkts in Komponenten die unabh ngig voneinander weiterentwi ckelt werden e Review berpr fung der Schritte 1 bis 3 des aktuellen Zyklus e Commitment Einverst ndnis ber den n chsten Zyklus herstellen Das mehrfache Durchlaufen dieser Schritte wird als Spirale dargestellt Die Fl che der Spi rale vergr ert sich mit jedem Schritt und stellt die akkumulierten Kosten dar die durch die bisherigen Aktivit ten angefallen sind Von seiner Absicht her ist das Spiralmodell somit ein risikogetriebenes Modell oberstes Ziel ist die Risikominimierung Zudem ist es ein offene
18. 0 Tage sl 0 uy lauff hige inkrementel verbesserte Software Abbildung 2 4 Sprint Prozess Quelle http de wikipedia org wiki Scrum 2010 09 23 stimmt danach mit dem Team wie das Sprintziel zu erreichen ist Daraus ergibt sich das Sprint Backlog in dem festgehalten wird was genau im kommenden Sprint umzu setzen ist In einem t glichen etwa 15 min tigem meist nach dem Mittagessen und oft im Stehen stattfindenden Daily Scrum oder Stand Up Meeting wird bestimmt wel che Themen aus dem Sprint Backlog von wem umgesetzt werden und in dem jeder die folgenden Fragen zu beantworten hat Was habe ich seit dem letzten Meeting erreicht Was plane ich bis zum n chsten Meeting umzusetzen Was behindert mich bei meiner Arbeit Im Daily Scrum haben nur die Teammitglieder und der Scrum Master Rede recht Am Ende eines Sprints wird dem Product Owner im Sprint Review Meeting das Sprintergebnis vorgestellt und von ihm entschieden ob es einen weiteren Sprint ge ben muss In diesem Falle wird das Product Backlog berarbeitet also Anforderungen hinzugef gt ge ndert oder umpriorisiert und der n chste Sprint gestartet Produkt Backlog Sprint Backlog Sprint 3 Die Post Game Phase Ziel dieser Phase ist die berf hrung des fertigen Systems in die Produktion beziehungsweise Anwendung Typischerweise geh ren hierzu die Erstel lung der Dokumentation die Durchf hrung von Systemtests und Akzeptanztests und die Auslieferung des Systems Scrum
19. Dateien zuletzt ausgecheckt wurden 2 Update Nachdem nderungen an einer oder mehreren Dateien im lokalen Workspace vorgenommen worden sind und der endg ltige oder bei gr eren nderungen zu mindest konsistente Zwischenstand des modifizierten Systems erreicht ist beginnt der Entwickler mit dem Update Befehl die Vorbereitungen die neuen Versionen der ge n derten Dateien zur ck ins Repository zu bergeben Der Update Befehl vergleicht zu n chst einfach alle lokalen Dateien mit denen des Repositorys Es k nnen sich dabei Konflikte ergeben wenn andere Entwickler seit dem letzten Check out Update oder Commit s u Dateien ge ndert haben Der Update Befehl zeigt dabei alle Unteschie de zur aktuellen Repository Version an und der Entwickler kann sie in seine lokale Version bernehmen eine Datei ver ndern Normalerweise k nnen Konflikte durch einfaches Zusammenf hren Merge gel st werden wenn unterschiedliche Teile einer Datei ver ndert wurden oder m ssen manuell ggf in Absprache mit den anderen beteiligten Entwicklern ausger umt werden Eine hnliche Funktion bernimmt in Eclipse der Befehl Synchronize 3 Commit Der Entwickler l dt die aktualisierten Dateine hoch ins Repository Dabei wird in CVS automatisch die Versionsnummer erh ht Im Falle eines Konfliktes muss in der Regel manuell nachgearbeitet werden Abb 5 3 Da jeder Enrwickler jede Datei ver ndern kann auf die er Zugriff hat geht CVS von ei nem op
20. Driver schreibt dabei den Code w hrend der andere der Navigator ber die Problemstellungen nachdenkt den geschriebenen Code kontrolliert und Probleme die ihm dabei auffallen sofort anspricht z B Schreibfehler oder logische Fehler Diese k nnen dann sofort im Gespr ch zu zweit gel st werden Die beiden Programmierer sollten sich bez glich dieser beiden Rollen periodisch abwechseln Auch die Zusammensetzung der Paare sollte sich regelm ig ndern Paarprogrammierung f hrt zu qualitativ signifikant h herwertigen Programmen als die Einzelprogrammierung 5 S 428 Ferner verfolgen traditionelle Entwicklungsmethoden eine Flie bandstrategie und be trachten die Entwickler Analysten Programmierer Tester als austauschbar innerhalb ihrer jeweiligen Gruppe Die agile Softgwareentwicklung dagegen konzentriert sich auf das in dividuelle K nnen und setzt keine Grenzen jeder Entwickler soll Wissen und Erfahrungen durch die Arbeit mit anderen gewinnen So durchl uft dasselbe Team alle Phasen eines Zy klus von der Analyse bis zur Funktionspr fung 2 3 2 eXtreme Programmierung XP Eine der verbreitetsten agilen Entwicklungsmodelle ist die eXtreme Programmierung XP Es eignet sich f r kleinere Projekte mit bis zu 15 Entwicklern in einem Umfeld mit sich rasch ndernden Anforderungen Oberstes Prinzip der eXtremen Programmierung ist Einfach heit und sie hei t extrem da sie alle aus Erfahrung gute Methoden in der
21. Faktor Funktionspunkte 3 x1 4 X2 Eingaben X1 einfach X2 mittel komplex Ausgaben einfach mittel komplex Abfragen einfach mittel komplex Datenbest nde einfach mittel komplex Schnittstellen einfach mittel komplex Ungewichtete Funktionspunkte p Puz Raj e N 01 01 OINI N A OM NI GA eA Os Ha w o Verflechtungen mit anderen Softwaresystemen 0 5 dezentrale Daten dezentrale Verarbeitung 0 5 Anzahl Transaktionen der Anwender 0 5 Verarbeitungslogik a Rechenoperationen 0 10 b Kontrollverfahren 0 5 c Ausnahmeregelungen 0 5 d Logik 0 5 Wiederverwendbarkeit 0 5 Konvertierungen des Datenbestands 0 5 Anpassbarkeit 0 5 Summe der Einflussfaktoren f bewerteter Einflussfaktor w f 100 0 7 bewertete Funktionspunkte p w p Einflussfaktoren vi aM Abbildung 6 4 Bewertungsformular der Funktionspunktanalyse nach http danae uni muenster de lux se minar ss01 Michaelsen pdf 47 Kapitel 7 Softwarequalit t 7 1 Qualit t und Anforderungen Wie von jedem anderen Produkt auch erwartet und ben tigt der Anwender von Software eine Qualit t Dieser Begriff ist allerdings sehr vage Softwarequalit t muss genauer defi niert werden und sollte idealerweise quantifizierbar sein um sie zu messen und bestimmen zu k nnen ob sie in ausreichend
22. Projektmanagements wird eine Aktivit t oft durch einen Meilenstein beendet Die Begriffe Phase und Aktivit t sind oft nicht trennscharf definiert im Projektmanagement wird ein Projekt blicherweise in Phasen eingeteilt 6 S 10 Vorphase Analyse gt Konzeption Realisierung Test gt Abnahme w hrend ein Software Projekt meist eher als Entwicklungsprozess verstanden wird der aus einzelnen Aktivit ten besteht In der Softwareentwicklung unterscheidet man gew hnlich die folgenden Aktivit ten oder Phasen 1 81 2 1 6 81 2 83 3 Aktivit t Ergebnis Meilenstein Anforderungsdefinition Requirements Lastenheft Analyse Specifications Pflichtenheft Sollkonzept Entwurf Design UML Diagramme Algorithmen Implementierung Implementation Programme Funktionspr fung Testing Abnahme Inbetriebnahme Deployment Installation der Software Schulungen Wartung amp Support Maintenance Software wird f r Anwender erstellt Das ist eine gegebene Zielgruppe beispielsweise ein Kunde ein System vielleicht auch eine Maschine Wie im Software Engineering blich wird der Anwender hier im Folgenden kurz Kunde genannt e Anforderungsdefinition oft auch Bedarfserfassung In diesem Prozess wird ermit telt was der Kunde tats chlich braucht Da bei dem Kunden im Allgemeinen spezielle Informatikkenntnisse nicht vorausgesetzt werden k nnen u
23. S dwestfalen University of Applied Sciences Fachhochschule l ci vu Fachbereich Technische Betriebswirtschaft Software Engineering Materialsammlung zur Vorlesung des ersten Teils des Moduls Application Engineering f r Wirtschaftsinformatiker des vierten Semesters Andreas de Vries Version 3 Januar 2011 Dieses Skript unterliegt der Creative Commons License 3 0 http creativecommons org licenses by nc 3 0 deed de 1 Was ist Software Engineering 4 Programmierleits tze und Best Practices Inhaltsverzeichnis 1 1 Die Softwarekrise 12 TUrsachen e 3er 2 a Be A Be ee ada a 1 3 Definition 2 2 Coon Der Zyklus der Softwareentwicklung 2 1 Soltwareentwickl ng als Projekt 2442 42 o ICA 2 1 1 Das Wasserfallmodelll 2 1 2 Das V Modell Projektmanagement und Qualit tssicherung 2 2 Softwareentwicklung als Prozess 2 2 1 Das Spiralmodel 2 2 2 Versionen Entwicklung Versioning 2 2 3 Der Rational Unified Process RUP 2 2 4 Das Eclipse Process Framework EPF 2 2 5 Open Source das Basarmodell 3 Psychologie des Software Engineering 2 3 1 Agile Softwareentwicklung 2 3 2 eXtreme Programmierung XP 2 4 Flexibles Rahmenmodell V Modell XT ul 2 Analyse und Entwurf mit UML 4 1 Programmierleits tze nach der Unix Philosophie 4 1 1 Klein ist sch n 4 1 2 Jedes Programm soll genau eine Sache gut machen
24. achl ssigbar ist Heute zu Beginn der 2010er Jahre hat sich Unicode als neuer Standard f r Textdaten etabliert und so werden ganz im Sinne der Unix Philosophie strukturierte Daten in XML und Unicode gespeichert 4 1 6 Nutze die Hebelwirkung von Software zu deinem Vorteil Durch einen Hebel kann man mit geringer Kraft gro e Lasten bewegen In diesem Sinne gilt es die Hebelwirkung leverage von Software zu erkennen und zu verwenden Gute Programmierer schreiben guten Code wirklich gro e Programmierer borgen guten Code Es bringt keinen Fortschritt das Rad immer wieder neu zu erfinden Es gilt den eigenen Stolz zu bezwingen und das sogenannte NIH Syndrom zu vermeiden engl Not Invented Here und auch Dinge die nicht selbst oder nicht im eigenen Haus erfunden worden sind einzusetzen Umgekehrt ist es wichtig anderen Leuten zu erlauben seinen eigenen Code zu verwenden damit diese mit ihrer Arbeit darauf aufbauen k nnen Automatisiere alles Ein m chtiges Mittel die Hebelwirkung der Software zum eigenen Vorteil einzusetzen ist es die Arbeit auf die Maschine zu bertragen Es ist Zeitverschwen dung etwas manuell zu machen wenn der Computer es auch tun kann Immer wiederkeh rende monotone Arbeiten sind typische Kandidaten f r eine Automatisierung Genau hier schl gt die Batchf higkeit von Programmen zu und das Konzept der vielen kleinen unab h ngigen Werkzeuge und der Filter das bei anderen Leits tzen angesprochen
25. allow phenomena or at least that they turn shallow pretty quick when exposed to a thousand eager co developers pounding on every single new release Accordingly you release often in order to get more corrections and as a beneficial side effect you have less to lose if an occasional botch gets out the door And that s it That s enough If Linus Law is false then any system as complex as the Linux kernel being hacked over by as many hands as the Linux kernel should at some point have collapsed under the weight of unforseen bad interactions and undiscovered deep bugs If it s true on the other hand it is sufficient to explain Linux s relative lack of bugginess Linux was the first project to make a conscious and successful effort to use the entire world as its talent pool I don t think it s a coincidence that the gestation period of Linux coincided with the birth of the World Wide Web and that Linux left its infancy during the same period in 1993 1994 that saw the takeoff of the ISP industry and the explosion of mainstream interest in the Internet Linus was the first person who learned how to play by the new rules that pervasive Internet made possible Eric S Raymond Nach Raymond basiert die kollaborative Innovation von Open Source auf demsel ben soziologischen Effekt der auch der Delphi Methode unterliegt n mlich dass der Durchschnitt aller Meinungen einer breiten Masse an Experten signifikant besser ist a
26. anik mache ansahen geh ren die weltweiten Anstrengungen zum Y2K Problem zu den er folgreichsten Softwareprojekten berhaupt F r Software gilt nun einmal hnlich wie f r viele andere Dienstleistungen das Gesetz der asymmetrischen Aufmerkdamkeit Wenn sie ihren Zweck erf llt bemerkt es niemand nur Fehler und Bugs fallen auff Man sollte sich nichts vormachen das n chste Jahrtausendproblem mit wohl allen derzeitig laufenden Programmen ist zu l sen vor dem 31 12 9999 e Fiskus 1991 wurde von den Fianzministern von Bund und L ndern das Softwarepro jekt Fiskus begonnen das sp testens ab 2006 den 650 Finanz mtern der Bundesrepu blik Deutschland bringen sollte Es wurde 2004 als gescheitert erkl rt nach internen Sch tzungen beliefen sich die Kosten auf Betr ge zwischen 250 und 900 Millionen Eu ro Untersuchungen der Standish Gruppe aus den Jahren 1994 und 2004 versuchten die Entwicklung der Ergebnisse von Softwareprojekten zu beziffern Dabei wurden 1994 ins Jahr erfolgreich kritisch aufgegeben 1994 16 50 31 2004 29 53 18 Tabelle 1 1 Bewertung von Softwareprojekten in den USA nach Untersuchungen der Standish Group Hier bezeichnet erfolgreich die Projekte die im Zeit und Budgetrahmen fertiggestellt wurden kritisch die jenigen die den Zeit oder Budgetrahmen erheblich berschritten 1994 um ber 100 oder mit erheblich reduziertem Funktionsumfang ausgeliefert wurden Zahlen aus S 3 5 gesa
27. auen Wird aber das Problem umfangreicher so wird es notwendig im Team zu arbeiten und den Zweck der verschiedenen Komponenten des Projekts und deren Beziehungen untereinander schriftlich festzuhalten und zu protokollieren In der Regel m ssen bereits erstellte Softwaremodule lEntsprechend wird ein Zugschaffner wohl nur zum Zeitplan seines Zuges angesprochen wenn dieser nicht eingehalten wird Ein Dankesch n nach p nktlicher Ankunft w rde h chstwahrscheinlich als ironisch aufgefasst Ahttp www cs utexas edu users EWD ewd03xx EWD340 PDF eingebunden werden so dass eine Dokumentation ber ihre Funktionen und ihre Schnitt stellen unumg nglich ist Ein weiteres Mittel zur Bew ltigung der Komplexit t sind die Anwendung von Standardisierungen Normen oder Konventionen z B ISO Normen f r Prozesse oder zur Qualit tskontrolle festgelegte Struktur von Programmen oder Namens konventionen Oft tr gt eine mangelnde Qualit tssicherung zum Scheitern von Softwareprojekten bei Ebenso kann eine schlechte Projektorganisation verantwortlich f r das Scheitern von Projek ten sein wie ungen gende Einbeziehung des Anwenders und damit einhergehender Know How Verlust Zeitdruck oder fehlerhafte Zielvorstellungen Oft ist der Projekttreiber auch nicht ein Anwender oder die Gesch ftsf hrung sondern die IT Abteilung was potentiell zu nicht an den Anwenderbed rfnissen orientierten Ergebnissen und letztlich zu Akzep tanzproblemen f hrt 1
28. business process modeling werden die f r das Sys tem relevanten Gesch ftsprozesse in so genannten Anwendungsf llen gem UML dokumentiert vgl 3 um ein gemeinsames Verst ndnis des Anwendungsumfelds zwischen Entwicklern und Anwendern zu schaffen 18 Business Modeling Requirements Analysis amp Design Implementation Test Deployment Configuration amp Change Mgmt Project Management Environment Iterations Abbildung 2 6 Der RUP Rational Software Corporation jetzt IBM e In der Anforderungsdefinition requirements wird ermittelt was das Anwendungssys tem leisten soll e Gegenstand von Softwarespezifikation und Entwurf analysis and design sind die pr zise Spezifikation und der Entwurf des Systems Zentrales Ergebnis sind die Klassendia gramme nach UML die das System modellieren e In der Implementierung implementation werden die einzelnen Klassen aus der Ent wurfsdisziplin programmiert und zusammengef hrt Besonderes Augenmerk wird hierbei auf Aspekte der Wiederverwendung durch Schnittstellen Module und Kom ponenten gelegt e Durch den Test test werden sowohl die einzelnen Module und Komponenten und ihr Zusammenspiel als auch die Erf llung der f r das System definierten Anforderungen berpr ft e Die Inbetriebnahme deployment umfasst Installation des Systems Schulung der An wender Beta Tests usw Die Disziplinen des RUP durchl ufen jeweils gleichzeitig die vier Phasen K
29. ch welcher Gr e aufgrund seiner besonderen Funktionalit t schwer zu verstehen sein aber dies ist die Ausnahme Es gibt keine allge meing ltige Regel wann aus einem kleinen Programm ein gro es wird Warnzeichen sind z B wenn der Entwickler bei einer Fehlermeldung selbst nicht mehr wei wo sie herkommt oder wenn man den Quelltext ausdrucken muss um den berblick zu wahren Kleine Pro gramme sind leicht zu warten Da ein kleines Programm im allgemeinen leicht zu verstehen ist ist es auch leicht zu warten korrigieren erweitern portieren lDieser Abschnitt ist eine Zusammenfassung des Buchs Mike Gancarz The UNIX Philosophy Digital Press 1995 nach Christian Weisgerber Die Unix Philosophie 25 Juni 1998 http sites inka de mips unix unixphil html Antoine de Saint Exup ry in Terre des Hommes III L Avion p 60 1939 Original franz Il semble que la perfection soit atteinte non quand il n y a plus rien a ajouter mais quand il n y a plus rien retrancher 28 Kleine Programme verschlingen weniger Systemressourcen Sei es Plattenplatz oder Spei cher kleine Programme sind schonender im Umgang mit begrenzten Betriebsmitteln Man mag einwenden dass die Summe mehrerer kleiner Programme mehr Ressourcen ben tigt als ein gro es mit der gleichen Funktionalit t aber Kleine Programme lassen sich leichter mit anderen Werkzeugen kombinieren Wie wei ter unten noch angesprochen wird liegt die wahre M chtigke
30. cht einmal polynomial ist Die zyklomatische Komplexit t besagt also nichts ber die Laufzeit eines Programms diese Metrik misst lediglich den Verzweigungsgrad von Quelltext Betrachten wir beispielsweise die beiden folgenden Methoden die jeweils eine Jahres zahl n als Eingabe erwarten und genau dann true zur ck geben wenn n ein Schaltjahr ist Hierbei ist n ein Schaltjahr wenn n durch 4 teilbar ist au er wenn es durch 100 teilbar ist es sein denn Ausnahe von der Ausnahme wenn n durch 400 teilbar ist public boolean istSchaltjahr int n if n 4 0 return false Schaltjahre sind immer durch 4 teilbar else if n 100 0 return true aber nicht durch 100 dann sicher Schaltjahr else if n 400 0 return true sonst falls durch 400 doch Schaltjahr else return false alle anderen keine Schaltjahr public boolean istSchaltjahr int n return n 4 0 amp amp n 100 0 n 400 0 2Denken Sie an die Formel f r die Oberfl che eines Sph roids im 1 Semester 388 4 im Skript Algorithms and Optimization http www3 fh swf de fotbw devries download algorithmics pd 42 Das obere Quelltextfragment weist 3 Verweigungen auf und hat damit die zyklomatische Komplexit t 4 das untere besteht aus nur einer wenn auch komplizierteren Formel und hat somit die zyklomatische Komplexit t 1 Wenn Entwickler wissen dass ihre Leistungen gem d
31. cket Abbildung 6 1 Ein Quelltextfragment Leerzeilen sind es entsprechend 12 Zeilen ohne Kommentare nur noch 8 Zeilen Welche Z hlweise angemessen ist h ngt von der Absicht ab die man mit der Metrik verfolgt e Man m chte absch tzen wie viele Ordner ein Papierausdruck des Quelltext f llen w rde Dazu m ssen alle Zeilen gez hlt werden auch Leerzeilen denn sie nehmen auf dem Papier gleich viel Raum ein e Man m chte bewerten wieviel ein Programmierteam geleistet hat Die LOC sollen dann den erstellten Programmumfang messen d h es werden Kommentarzeilen mit gez hlt Leerzeilen allerdings nicht denn sie stellen keine Leistung dar e Man m chte absch tzen wie schwer es einem Neueinsteiger fallen wird sich in das Programm einzuarbeiten Je l nger das Programm desto l nger wird die Einarbeitung dauern allerdings machen Kommentare das Programm eher verst ndlich daher soll ten sie nicht mitgez hlt werden Anhand des Beispiels der LOC kann man ein rekursives Ph nomen verdeutlichen das all gemein jede Softwaremetrik betrifft Eine Messung beeinflusst den gemessenen Aspekt Wenn n mlich beispielsweise Entwickler wissen dass ihre Leistung nach LOC ohne Leerzei chen und mit Kommentarzeilen bewertet und vielleicht sogar bezahlt wird werden sie ihr Programmierverhalten danach ausrichten und mehr Kommentare schreiben Ist das nicht Verzerrung des Ergebnisses ja Betrug Keineswegs eine Met
32. derungen gestiegen oder Sicherheitsl cken bzw Fehler Bugs aufgetreten sind Solche Modifikationen werden blicherweise durch Patches Flicken durchgef hrt also punktuelle nderungen der Software H ufig kann der bemerkenswerte rekursive Effekt beobachtet werden dass die neu eingesetzte Software den Bereich ver ndert in dem sie eingesetzt wird Beispielsweise k nnte die zur Beschleunigung seiner Arbeitsabl ufe eingef hrte Software bei einem Steuerberater dazu f hren dass er neue Kunden gewinnt Damit ist er nun aber von der Software abh ngig er kann nicht mehr ohne sie auskommen Statistiken zeigen dass der gr te Teil der Ausgaben bei Software im Wartungsbereich lie gen oft bis zu 80 der Gesamtkosten 5 S 419 Der internationale Standard zur Methodenbeschreibung von Auswahl Implementierung und berwachung des Lebenszyklus von Software ist ISO 12207 12 Prototyping Oft wird vor der Entwurfsphase ein Prototyp der des Softwaresystems oder wichtiger Sys temteile erstellt die Anforderungsspezifikation zu validieren Der Prototyp wird so lange berarbeitet bis Kunde bzw Anwender zustimmen Ein Prototyp veranschaulicht nur grunds tzliche Aspekte der Software Typisch ist die Erstellung von Prototypen der Benutzeroberfl che horizontale Prototypen um bestimmte Aspekte der Benutzeroberfl che zu beleuchten im Extremfall k nnen solche Prototypen aus Papierskizzen bestehen zur Verdeutlichung ganzer Ab
33. derungsermittlung software requirements Entwurf software design Implementierung software construction Testen software testing Wartung software maintenance e Konfigurationsmanagement software configuration management Projektmanagement und Metriken software engineering management 9 e Vorgehensmodelle software engineering process e Werkzeuge und Methoden software engineering tools and methods e Softwarequalit t software quality Demnach ist Software Engineering eine sehr fassettenreiche Disziplin die Querbez ge zu den Ingenieurs und Wirtschaftswissenschaften aber auch zur Kommunikations und Ar beitspsychologie hat In diesem Skript werden nur einige dieser Themen angerissen werden k nnen 10 Kapitel 2 Der Zyklus der Softwareentwicklung Um Managementmethoden f r das Software Engineering entwickeln zu k nnen muss man zuerst den Prozess der Softwareentwicklung verstehen Ein wesentlicher Punkt dazu ist das Vorgehensmodell Ein Vorgehensmodell auch Lebenszyklusmodell gliedert im Allgemeinen einen Gestaltungs oder Produktionsprozess in strukturierte Aktivit ten oder Phasen denen wiederum entsprechende Methoden und Techniken der Organisation zugeordnet sind Auf gabe eines Vorgehensmodells ist es die allgemein in einem Gestaltungsprozess auftretenden Aufgabenstellungen und Aktivit ten in ihrer logischen Ordnung darzustellen Wer macht was zu welcher Zeit und mit welchem Ergebnis Im Rahmen eines
34. e einfache Folge von Befehlen ist nicht schwierig zu verstehen was ein Programm schwierig macht sind bedingte Anweisungen also Verzweigungen und Schleifen Die zyklomatische Komplexit t ist so definiert dass man sie aus dem Quelltext einer strukturierten Programmiersprache ablesen kann 9 S 61 Anzahl der Verzweigungen if und Zweige bei switch case Anzahl der Schleifen for while do while 1 zyklomatische Komplexit t Die stets hinzu addierte 1 ist im Prinzip willk rlich und bewirkt dass selbst das einfachste Programm ohne eine Anweisung mindestens 1 ergibt Nach McCabe unterscheidet man drei Klassen von zyklomatischer Komplexit t n mlich niedrig f r eine zyklomatische Kom plexit t bis 10 mittel f r eine zyklomatische Komplexit t zwischen 10 und 20 hoch f r eine zyklomatische Komplexit t gr er als 20 und kleiner als 50 und undurchschaubar f r eine zyklomatische Komplexit t gr er als 50 Interessanterweise w rde eine noch so komplizierte mathematische Gleichung die zy klomatische Komplexit t nicht erh hen da dort keine Verzweigung auftaucht Die derzeit schnellste bekannteste L sung des Problem des Handlungsreisenden TSPP eine L sung ber die dynamische Optimierung besteht aus lediglich 4 Schleifen und einer bedingten An weisung zum Schreiben einer Tabelle hat also die zyklomatische Komplexit t 5 w hrend die Zeitkomplexit t dieses Algorithmus bez glich der zu besuchenden Orte ni
35. ebene und durch die immer wieder durchzuf hrenden Tests auf der funktionalen Ebene Das Vorge hensmodell des XP ist evolution r und umfasst in jedem Iterationsschritt das Refactoring worunter man alle Ma nahmen versteht durch die die Qualit t der Software und insbeson dere des Entwurfs verbessert wird ohne dass die Funktionalit ten ge ndert werden Re factorings sollen die vorliegende Software soweit verbessern dass sie lesbar verst ndlich wartbar und erweiterbar wird Es ist dazu extra ein spezieller Arbeitsschritt vorgesehen der also nicht direkt zur Erweiterung der Funktionalit t beitr gt und somit scheinbar unpro duktiv ist 23 gt Entwurf rl Anforderungser Testfall mittlung Stories spezifikation Masterplanung Iterations Stories planung i Implemen i Refactoring tierung Test durchf hrung Release Abbildung 2 7 Das Vorgehensmodell von XP Ein grundlegendes Element bei XP bilden die Stories Szenarien die der Beschreibung der Benutzeranforderungen dienen und vergleichbar mit den Anwendungsf llen der UML sind Ziel der Stories ist allerdings weniger die Erstellung einer vollst ndigen Spezfikation sondern vielmehr die Beschreibung eines Kundenwunsches der mit einer Priorit t versehen als Einheit f r die Masterplanung verwendet wird Im Laufe des Entwicklungsprozesses
36. em Ma e vorhanden ist oder nicht Definition 7 1 Softwarequalit t oft auch u ere Qualit t oder fachliche Qualit t 4 ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts bez glich ihrer Eignung festgelegte oder vorausgesetzte Erfordernisse zu erf llen 2 Insbesondere um fasst sie die Korrektheit die Zuverl ssigkeit und die Bedienbarkeit von Software Wie Qualit t allgemein hat Softwarequalit t also einen subjektiven Wert f r den Anwen der blicherweise denkt man an Softwarequalit t im Alltag nur wenn etwas mit ihr nicht stimmt Hat man beispielsweise gerade eine Online berweisung abgeschickt und bleibt das Programm pl tzlich stecken und reagiert nicht mehr was ist zu tun Ist das Geld ber wiesen Wenn nicht steht eine Mahnung ins Haus also nochmal berweisen wenn die berweisung beim ersten Mal dann aber doch geklappt hat kommt es zu einer Doppel berweisung berzogenem Konto und hohen Zinsen In diesem Beispiel w rde man un ter Softwarequalit t nicht die Verhinderung von Verbindungsproblemen verstehen sondern die schnelle und zuverl ssige berpr fbarkeit einer berweisung Zur Erf llung der Erfordernisse in Definition 7 1 miissen die Erfordernisse der Soft ware oder auch die Erwartungen an sie klar definiert sein Erst dann k nnen sie im Er stellungsprozess nicht falsch verstanden werden und permanent berpr ft und gemessen werden Mit den
37. em McCabe Wert berechnet wer den werden sie ihren Code dahin gehend optimieren m glichst wenig Verzweigungen oder Schleifen und m glichst viele Formeln zu verwenden Letztendlich wird er dadurch ber sichtlicher man kann ihn leichter warten die Fehleranf lligkeit wird geringer und verblie bene Fehler werden einfacher gefunden 6 3 Objektmetriken Bei der Verwendung einer objektorientierten Sprache funktioniert die Messung der zyklo matischen Komplexit t zwar immer noch allerdings ber cksichtigt sie in keiner Weise Me thodenaufrufe Nun kann ein Programm mit vielen Methodenaufrufen genauso un ber sichtlich sein wie eines mit vielen Verzweigungen in einer l ngeren Methode Daher wurde f r objektorientierte Sprachen verschiedene Metriken eingef hrt die man unter dem Begriff Objektmetriken oder objektorientierte Metriken zusammenfasst 6 3 1 WMC WMC weighted methods per class 9 84 3 4 ist f r eine gegebene Klasse definiert durch WMC Summe der Komplexit ten aller Methoden der Klasse Die Komplexit t einer einzelnen Methode kann hierbei die zyklomatische Komplexit t sein Dann wird jede Methode zumindest als 1 gez hlt denn das ist der Minimalwert von McCa be und viele kleine Methoden f hren nach der Formel zu hohen ung nstigen WMC Werten ebenso wie wenige sehr gro e Methoden Im Sinne dieser Metrik wird also ein Entwickler seinen Code optimieren indem er die zyklomatische Komplexit t jeder einzelnen Methode eine
38. en wie man Rei fen wechselt oder wie man die Scheinwerfer die Blinker und das Standlicht bedient Bei Modifikationen des Autos kann der Hersteller das Handbuch weiterverwenden es m ssen nur die entsprechenden Abschnitte ge ndert werden Und dennoch gibt es gerade in ei nem guten Handbuch wichtige Informationen die dort nicht zu finden sind beipielsweise die Vorschrift dass Sie den linken Blinker setzen m ssen bevor Sie links abbiegen oder in welchen L ndern man auch tags ber mit eingeschaltetem Scheinwerfer fahren muss Nat rlich k nnen Module nicht hermetisch abgeriegelt und logisch unabh ngig vom Hauptprogramm oder auch von anderen Modulen funktionieren Modularit t bedeutet auch dass minimale Informationen modul bergreifend geteilt werden 32 Die Strukuren der geteilten Informationen die genormten Stecker und Buchsen wer den durch Schnittstellen interfaces bereitgestellt Sie enth lt alle Details dar ber welche In formationen Dienste verlangt werden aber nicht wie die Informationen geschaffen wer den In objektorientierten Programmiersprachen wie Java ist das Schnittstellenkonzept um gesetzt 4 3 1 Plug ins Plug ins oft auch Erweiterungen sind Beispiele spezieller Module die f r bestimmte Pro gramme geschrieben z B ein Browser werden und und deren Funktionalit t z B Plug In zum Lesen von PDF Dokumenten erweitern Dazu verwenden sie die von dem Hauptpro gramm angebo
39. entare gewonnen werden Die Entwickler dagegen arbeiten lokal auf 35 ihren Rechnern im sogenannten Workspace oder der Workbench D h die Entwicklung also editieren kompilieren testen und debuggen wird ausschlie lich auf den lokalen Rechnern der Teammitglieder durchgef hrt Um als Entwickler Schreibrechte zu haben muss man sich an dem CVS Server als User authentifiziert einloggen CVS verwendet ein Branch Modell um isolierte parallele Entwicklungen zu erm glichen die aber gegenseitig voneinander abh ngen Hierbei ist ein Branch eine Art verteilter Ar Workspace 1 Branch en check out im Repository 4 gt update 1 gt commit Workspace 2 gt Abbildung 5 2 Ablauf der kollaborativen Entwicklung das Branch Modell von CVS beitsspeicher der von den Teammitgliedern durch ihre nderungen am Projekt aktualisiert wird Ein Branch stellt somit stets einen aktuellen Zustand eines Teilprojekts dar der HEAD als spezieller Branch entsprechend repr sentiert das gesamte Projekt Ein Projekt wird zu Be ginn importiert d h auf dem Repository gespeichert Der Arbeitsablauf mit CVS geschieht danach wie folgt Abb 5 2 1 Checkout Ein Entwickler des Moduls holt sich zun chst den aktuellen Stand aller Da teien eines Projekts aus dem Repository Dies bezeichnet man bei CVS als ausche cken Dabei werden von CVS Metadaten angelegt die es erm glichen zu erkennen welche Versionen der
40. er anwendungen im Internet verdanken beruht auf der konsequenten Anwendung einiger weniger fundamentaler Prinzipien Eine der grundlegenden Annahmen der Unix Entwicklung war stets dass der Benutzer mit dem Computer umgehen kann dass er wei was er tut Als Folge daraus sind anders als in anderen Umgebungen Unix Programme nicht darauf ausgerichtet den Benutzer daran zu hindern etwas zu tun sondern ihm zu erm glichen ihre volle Leistungsf higkeit auszu sch pfen Die Grunds tze der Unix Philosophie sind gepr gt von konsequenter Einfachheit Motto KISS Keep it simple and stupid Im folgenden werden sie in einer Reihe von einpr gsamen Leits tzen zusammengefasst und diese jeweils erl utert Die sequentielle Darstellung soll nicht t uschen diese Prinzipien greifen alle ineinander und machen in ihrer Kombination die M chtigkeit des Systems aus 4 1 1 Klein ist sch n Perfektion scheint erreicht nicht wenn sich nichts mehr hinzuf gen l sst sondern wenn man nichts mehr wegnehmen kann Z gere nicht berholte Funktionalit ten wegzuwerfen wenn es ohne sie auch ohne Verlust an Effektivit t geht Wenn dein Quelltext sowohl besser als auch einfacher wird dann wei t du dass du es richtig machst Kleine Programme sind leicht zu verstehen Durch ihre begrenzte Quelltextl nge und Funktionalit t bleiben kleine Programme berschaubar was wiederum zu weniger Feh lern f hrt Nat rlich kann ein Programm glei
41. ert was der Kunde unter den Qualit tzielen konkret versteht 9 82 7 Normen und Standards k nnen dabei sehr helfen in ihnen sind Merkmale einheitlich und in der Regel eindeutig definiert 7 2 Kosten und Nutzen von Softwarequalit t Qualit tsma nahmen m ssen sich lohnen Sie werden letztendlich eingesetzt um die ei genen Kosten zu sparen Allerdings kosten sie selber auch und man muss kaufm nnisch gegenrechnen inwieweit sich die Gesamtsumme aus Fehlervermeidungskosten also den Ausgaben f r Qualit tsma nahmen und den Fehlerkosten also den Ausgaben f r Fehler beseitigung Haftung oder Entsch digung minimieren l sst Qualitativ kann man in der Rea lit t ein Kurvendiagramm wie in Abb 7 1 beobachten in dem die Fehlerkosten bei steigen dem Qualit tsaufwand gemessen z B in Arbeitszeit oder Ausgaben sinken w hrend die Fehlervermeidungskosten nahezu linear mit ihm steigen Entsprechend gibt es ein globales Minimum der Kurve der Qualit tskosten insgesamt der den optimalen Qualit tsaufwand bestimmt Eine fundamentale Eigenschaft von Qualit t offenbart sich in dem harmlosen Diagramm Perfekte Qualit t gibt es nur mit enorm hohem Qualit tsaufwand Im Grenzfall mit unendlichem Aufwand also nie Wie in jedem Markt gibt es eine win win Situation zwischen Nachfra ger und Anbieter wenn der Nachfrager f r seinen Preis das ihm erforderliche Maximum 49 Kosten 4 Qualit tskosten Fehlerverh tungs und Pr fk
42. erungen und Regelungen die von Eingangsgr en abh ngen k nnen die ihrerseits kaum pr zise einzustellen sind z B eine Spannung von 3 0 Volt 5 Nat rlich kann es auch vorkommen dass sowohl Ist als auch Sollwert falsch sind im schlimmsten Fall sogar denselben falschen Wert annehmen Das kann passieren wenn man bei der Programmierung denselben Denkfehler macht wie bei der Erstellung Gegen diesen Effekt kann helfen mehrere unabh ngige Tester die Testf lle erstelen zu lassen so dass die Wahrscheinlichkeit derselben Denkfehler minimiert wird 7 3 2 Erstellen von Testf llen Black Box und Glass Box Ein Testfall beschreibt welche Ergebnisse die Software bei einer spezifizerten Eingabe produ ziert Man kann Testf lle also eindeutig in einer Tabelle mit Spalten f r die Eingaben und f r die erwarteten Ergebnisse oder Reaktionen definieren Sehr verbreitet bei der Entwicklung mit Java ist die Erfassung der Testf lle in ausf hrbarem Quelltext durch das Open Source Testframework JUnit Man braucht in der Regel ziemlich viele Testf lle je nach Systemgr e von einigen Dut zenden bis zu tausenden Testf lle zu erstellen ist die schwierigste aber auch interessanteste Aufgabe der Testvorbereitung Man unterscheidet grob zwei Ans tze Beim Black Box Test nimmt man sich die Spezifikation vor und leitet daraus Testf lle ab In der Spezifikation stehen alle dokumentierten Anforderungen daher ist sie der Bezugs punkt f r die T
43. ests Motto F r jede Anforderung mindestens einen Testfall Man inter essiert sich bei diesem Ansatz nur daf r wie sich das System laut Spezifikation verhalten soll nicht aber daf r wie es intern aufgebaut ist Man betrachtet das System also als Black Box deren Inneres man nicht sehen kann Entsprechend kann man in den Testf llen nur das abdecken was man ohne Kenntnis des Innern wei 51 Der zweite Ansatz der Glass Box Test oder White Box Test der sich an der Struktur der Software orientiert Motto Die Testf lle sollen den Quelltext berdecken wo gibt es schwie rige oder komplizierte Stellen im Quelltext an denen leicht Fehler auftreten k nnen Wur den mit den bisherigen Testf llen alle inneren Kombinationsm glichkeiten und Abl ufe ge pr ft Insbesondere bei objektorientierten Sprachen in denen Objekte oder Klassen andere Objekte oder Klassen benutzen gilt die Regel Stets das Benutzte vor dem Benutzenden tes ten D h bei Assoziationen und Kompositionen wird die verwendete vor der verwenden den Klasse getestet bei Vererbungshierarchien die Superklasse vor der erbenden Klasse 9 S 108f Beide Ans tze Black Box und Glass Box sind systematische Ans tz mit ihren eigenen Vor und Nachteilen die sich einander erg nzen aber nicht ersetzen ITestf lle sollen also die Anforderungen abdecken und den Quelltext berdecken 52 Literaturverzeichnis 1 BALZERT H Lehrbuch der Software Techni
44. fen 3Die Delphi Methode auch Delphi Studie oder Delphi Befragung ist ein systematisches mehrstufiges Befra gungsverfahren mit R ckkopplung um zuk nftige Ereignisse oder Trends sch tzen zu k nnen 21 Historisch war Linux das erste Open Source Projekt in dieser Form Es entstand 1991 durch Linus Torvalds aus einer Terminalemulation f r die damaligen Unix Systeme der Universi t ten auf Basis des Minix Systems von Andrew Tanenbaum an der Universit t Amsterdam und des freien GNU C Compilers Die erste Version 0 01 von Linux wurde am 17 9 1991 auf einem ffentlichen FTP Server bereitgestellt Torvalds gab Linux zun chst unter einer eigenen propriet ren Lizenz heraus erst die Mitte Dezember 1992 ver ffentlichte Version 0 99 war unter der GNU GPL Durch diesen Schritt erst wurde Linux ein freies Betriebssys tem und erst jetzt zog es weltweit viele Programmierer an um sich an der Entwicklung von Linux und GNU zu beteiligen Durch das damals entstehende Internet konnte so der Entwicklungszyklus rapide beschleunigt werden es gab oft mehrere Releases von Linux an einem Tag Je schneller die Release Wechsel erfolgten desto effizienter wurde die Fehlerbe hebung da die Wahrscheinlichkeit dass mehrere Entwickler an demselben Fehler arbeiteten und sich damit wom glich behinderten geringer wurde Ebenso bezeichnete Torvalds be stimmte Versionen des Linuxkerns als stabil und stellte sie auch zuk nftig bereit so dass die Anwende
45. fen fest Das Ende jeder Projektstufe ist durch einen Entscheidungs punkt oder Meilenstein versehen f r den wiederum Kriterien erf llt sein m ssen zum Bei spiel zu erstellende oder zu berpr fende Produkte Im V Modell XT sind verschiedene Projektdurchf hrungsstrategien verf gbar so unter Anderem die inkrementelle Systement wicklung die komponentenbasierte Systementwicklung und die agile Systementwicklung to tailor schneidern In der Tat steht XT f r extreme Tailoring und soll die Anpassbarkeit des Modells an die jeweiligen Bed rfnisse ausdr cken 25 Bei der Einf hrung und Umsetzung des V Modells XT geht man blicherweise zwei stufig vor Zun chst wird das V Modell XT auf die unternehmensspezifischen Bed rfnisse angepasst Durc dieses Tailoring auf Unternehmensebene entsteht so ein unternehmensspe zifisches Vorgehensmodell 26 Kapitel 3 Analyse und Entwurf mit UML Inhalte von als e Book http www springerlink com content m3124 unter springerlink com Die Kapitel des e Books sind nur ber den FH Zugang d h Poolr u me oder VPN kostenfrei als Lehrmaterial zu dieser Veranstaltung herunterladbar 27 Kapitel 4 Programmierleits tze und Best Practices 4 1 Programmierleits tze nach der Unix Philosophie Pie kontinuierlich steigende Popularit t der Unix Betriebssysteme seit ihren Anf ngen und ihre resultierende heutige M chtigkeit denen sie ihren ersten Rang als Plattform f r Serv
46. g vollzieht 90 des Programmentwurfs sollten vor dem ersten Compilerlauf vollzogen sein so oder hnlich heift es Das klingt vern nftig in der Theorie beruht aber auf der un realistischen Annahme dass der Entwurf von vornherein schon komplett berschaubar ist Die Erstellung eines Prototypen ist ein lehrreicher Vorgang Man kann fr hzeitig erken nen ob das Projekt in dieser Form berhaupt realisierbar ist und wie die eigenen Vorstel lungen sich in der Praxis bew hren Es ist besser eine fehlerhafte Annahme fr hzeitig zu erkennen als kurz vor Fertigstellungsfrist Die fr he Anfertigung eines Prototypen verringert Risiken Die Erfahrung zeigt dass Programmspezifikationen in der Zeit die ein Projekt zur Fertigstellung braucht nicht stabil sind und dass Anwender und Auftraggeber oft Spezifikationen abgeben die vom Program mierer anders verstanden werden oder schlicht falsch sind Ein fr her Prototyp hilft solche Fehler zu erkennen bevor Zeit und Arbeit vergeudet sind 4 1 4 Portabilit t geht ber Effizienz Der m chtigste Computer ist nicht der mit der schnellsten CPU und dem meisten Speicher sondern der der am meisten benutzt wird Ein Laptop den man den ganzen Tag bei sich hat kann eine viel gr ere Produktivit t haben als der vielfach leistungsf higer Tischrechner der unbenutzt im B ro steht Aber auch in der umgekehrten Richtung ist Portabilit t Trumpf Es hat keinen Sinn zuviel Zeit damit zu vergeuden e
47. igkeit bewirken kann 6 3 4 CBO oder Ce CBO coupling between object classes 4 misst die Kopplung einer gegebenen Klasse mit an deren durch ausgehende Beziehungen Ce efferent coupling zu anderen Klassen beispiels weise durch Methodenaufrufe Attributzugriffe Vererbungen Eingabeparameter R ckga betypen oder Exceptions Bestehen viele Verbindungen zu anderen Klassen so kann das der Modularisierung widersprechen und die Wiederverwendung erschweren Au erdem kann diese Metrik als ein Indikator f r den Testumfang dienen der durch komplexe Beziehungs geflechte steigt 6 3 5 RFC RFC response for a class 4 misst die Anzahl der unterschiedlichen Methoden die direkt in den Methoden der Klasse aufgerufen werden Je mehr Methoden aufgerufen werden desto komplexer ist die Implementierung und desto h her Testaufwand 6 3 6 LCOM LCOM lack of cohesion in methods 4 ist der relative Anteil jeweils zweier Methoden der betrachteten Klasse die keine oder nur wenige ihrer Attribute gemeinsam nutzen Diese Metrik misst also den inneren Zusammenhalt der Klasse Eine Klasse mit einem niedrigen LCOM ist fehleranf llig da dies auf ein schlechtes Design schlie en l sst 6 4 Analysemetriken Neben den Softwaremetriken die eine absolute Zahl f r eine einzelne Klasse ausgeben gibt es die Analysemetriken die im gesamten System Abweichungen von vorgegebenen Regeln oder festgelegten Standards identifizieren oder potenzielle Fehler
48. ili t t die heute zunehmend die Grenzen zwischen den klassischen Ingenieurswissenschaften und der Informatik verschwimmen l sst Wo ist denn genau der Unterschied zwischen einer Maschine einem Roboter oder einem Computer So komplex das Produkt Software so schwierig ist auch dessen Herstellung Seit den 1960er Jahren gibt es Versuche den Herstellungsprozess von Software mit ingenieursm i gen Ans tzen anzugehen und zu planen In diesem Geiste bildete sich der Name Software Engineering und mit ihm eine neue wissenschaftliche Disziplin Als wichtiges Element des Software Engineering erwies sich von Anfang an das Projektmanagement mit der Zeit entstanden jedoch zus tzlich spezifisch programmiertechnische Ans tze die in klassischen Entwicklungsprozessen so gar nicht m glich waren wie kollaborative Softwareentwicklung in gro en Teams insbesondere seit den 1990er Jahren ganz neue und hocheffiziente sozia le Erstellungsprozesse im Zusammenhang mit Open Source Projekten mit tausenden von Entwicklern vernetzt ber das Internet Das vorliegende Skript ber Software Engineering behandelt den ersten Teils des ber greifenden Moduls Application Engineering Das ist hier verstanden als diejenige Disziplin die sich mit Techniken und Methoden zur arbeitsteiligen ingenieursm igen Erstellung ge brauchstauglicher Anwendungs und Informationssysteme befasst Das Application Enginee ring erg nzt damit das Software Engineering also die s
49. in Programm durch systemspezifische Optimierungen 29 schneller zu machen N chstes Jahr bei den heutigen Produktzyklen vielleicht schon n chs tes Quartal wird die Hardware schneller sein Die effizienteste Programmierung ist selten die portabelste Niemand wird sich mehr daf r interessieren dass eine Applikation fr her auf einer bestimmten Plattform viel schneller als die anderen war wenn man sie auf der neuen Plattform wo alle schneller sind erst gar nicht einsetzen kann Portable Software verringert auch den Bedarf f r Benutzerschulung Gute Programme sterben nie sie werden auf neue Plattformen portiert 4 1 5 Speichere numerische Daten in ASCII Dateien Genauso wichtig wie die Portabilit t von Programmen ist die Portabilit t der Daten Ein wesentlicher Beitrag dazu ist numerische Daten nicht in einem Bin rformat zu speichern sondern in ASCII Text ASCII Text mit allen seinen Schw chen ist das verbreitetste Austauschformat Er unter liegt keinen Problemen mit der Byte Reihenfolge oder verschiedenen Flie kommaformaten die den Austausch von Bin rdaten immer wieder komplizieren Er ist leicht zu lesen und mit normalen Editoren und unter Einsatz der Unix Text Werkzeuge wie cut diff grep sed sort wc usw leicht zu bearbeiten Bessere Portabilit t berwiegt gegen ber dem Geschwin digkeitsverlust durch die Wandlung bei der Ein Ausgabe der in der Praxis im Vergleich zur eigentlichen Verarbeitungszeit ohnehin meist vern
50. ingungen auf dem Mars zu erkunden Der Orbi ter erreichte am 23 September 1999 den Mars ging dann aber verloren Der sp ter eingesetzte Untersuchungsausschuss fand heraus dass die Bahn des Orbiters um 170 km zu niedrig verlief weil ein einzelnes Modul englische L ngenma e benutzte w h rend andere den Vorgaben der NASA entsprechend die international gebr uchlichen SI Einheiten verwendeten Unter den im Bericht des Untersuchungsausschuss aufge f hrten Ursachen befand sich ein Vermerk ber unzureichende Kommunikation zwischen den Entwicklern und den Programmierteams e Mars Polar Lander Auch der Mars Polar Lander der sechs Wochen sp ter auf dem Mars landen sollte ging verloren Der eingesetzte Untersuchungsausschuss identifi zierte einen Softwarefehler als wahrscheinlichste Ursache des Verlusts Hintergrund war dass die Iriebwerke des Landers sofort nach der Landung abgeschaltet werden 6 sollten da er sonst umkippen w rde Sensoren an den Landef en des Polar Landers erzeugten noch vor dem Oberfl chenkontakt ein Signal Allerdings war bekannt dass die Sensoren gelegentlich unechte Signale erzeugen konnten und so war die Software so programmiert dass sie solche Signale erkennen konnte indem sie zwei aufeinander folgende Signale verglich und nur dann reagierte wenn beide denselben Wert hatten Nun konnte es jedoch zur Erzeugung l ngerer Kontaktsignale kommen wenn die Lan def e von ihrer Stauposition in die Landeposition
51. it des Unix Konzepts in der Kombinierbarkeit vieler kleiner Werkzeuge Kein Autor kann alle Anwendungen die seine Programme erfahren werden voraussehen Gro e monolithische Anwendungen sind we nig flexibel Eine Sammlung kleiner handlicher Programme ist neuen Anforderungen viel eher gewachsen 4 1 2 Jedes Programm soll genau eine Sache gut machen Kleine Programme haben meistens nur eine Funktion Programme mit nur einer Funktion neigen wiederum dazu klein zu sein was sich mit dem ersten Leitsatz erg nzt Ein viel kritisiertes Problem ist der sogenannte creeping featurism der schleichende Einzug von immer mehr Funktionalit t die eigentlich berfl ssig ist oder ausgelagert geh rt und die kleine Programme zu gro en aufbl ht Einige Fragen die man sich stellen kann um das Wuchern des sch pferischen Drangs in sinnvolle Bahnen zu lenken Muss ein Programm interaktiv sein oder reicht es nicht wenn der Benutzer die Eingaben in eine Datei oder ber Kommandozeilenparameter macht Falls Ein Ausgabedaten besonders formatiert werden sollen gibt es dann nicht schon andere Werkzeuge die das bernehmen k nnen Gibt es berhaupt nicht bereits ein hnliches Pro gramm das man einfach verwenden kann 4 1 3 Erstelle so schnell wie m glich einen Prototyp Dieser Leitsatz steht im Widerspruch zur klassischen Lehre dass der Entwurf eines Pro gramms schon abgeschlossen sein soll bevor man dann im letzten Schritt die Implementie run
52. itel 1 Was ist Software Engineering Wer sich an die Vergangenheit nicht erinnert ist dazu verdammt sie zu wiederholen George Santayana Wer sich an die Vergangenheit nicht erinnert ist dazu verdammt deren Erfolge nicht zu wiederholen Barry Boehm ObjektSpektrum 6 2008 Bevor wir uns der Definition des Software Engineering dessen Entwicklung und Metho den widmen betrachten wir zun chst das historische Ph nomen der Softwarekrise Ende der 1960er Jahre das die Ursache zu dessen Entstehung und Notwendigkeit besteht 1 1 Die Softwarekrise Auf einer NATO Tagung 1968 in Garmisch Partenkirchen wurde das Problem diskutiert dass erstmalig die Kosten f r die Software die Kosten f r die Hardware berstiegen und die ersten gro en Software Projekte gescheitert waren Dort wurde der Begriff des Software Engineering gepr gt Die Idee war als Vorbild die ingenieursm ige Herangehensweise an die Produktion zu bernehmen und somit Software als komplexes industrielles Produkt zu sehen Doch wo ist eigentlich das Problem Zun chst einmal bleibt festzustellen dass bis in die j ngste Vergangenheit Softwareprojekte grandios scheitern Beispiele f r die spektakul rs ten und teuersten davon seien hier erw hnt 5 S 410ff 81 2 e Mars Climate Orbiter Im Jahr 1998 startete die NASA den Mars Climate Orbiter ei ne Sonde deren Mission darin bestand einen Orbit um den Mars zu erlangen und von dort aus die klimatischen Bed
53. itory speichert Im Repository ist damit am Ende die Branch Version 3 in den Trunk zusammengef hrt gestrichelte Linie 39 Kapitel 6 Technische Qualit t Softwaremetriken You can t control what you can t measure Tom DeMarcd Eine Softwaremetrik ist ein Ma f r eine bestimmte Eigenschaft von Software oder seiner Spezifikationen Ziel ist es f r eine Software Ma zahlen zu bestimmen und so Eigenschaften zu messen und somit vergleichbar zu machen Auf diese Weise soll Softwareentwicklung quantitativ planbar und kontrollierbar werden Softwaremetriken spielen eine wesentliche Rolle bei der Messung der technischen Qua lit t der Software oder inneren Qualit t die vom Software Ersteller selbst wahrgenommen wird im Gegensatz zur u eren fachlichen Qualit t die vom Anwender wahrgenom men wird s Def 7 1 lauf S 48 Die technische Qualit t wird bestimmt anhand von Kriterien wie Anpassbarkeit Erweiterbarkeit Wiederverwendbarkeit Administrierbarkeit Robust heit Testbarkeit oder Verst ndlichkeit 4 Softwaremetriken lassen sich grob in eine der vier Kategorien Quantit tsmetrik Kom plexit tsmetrik Objektmetrik oder Analysemetrik unterteilen Sie lassen sich in den meisten F llen allein anhand des Quelltextes ermitteln 6 1 Lines of Code LOC Lines of Code LOC auch Source Lines of Code SLOC gibt die Anzahl der Quelltextzeilen eines Programms von Software an Es ist eine der gebr uchlichsten Software
54. k Software Entwicklung Heidelberg Berlin Spektrum Akademischer Verlag 1996 2 BALZERT H Lehrbuch der Software Technik Software Management Software Qualit tssi cherung Unternehmensmodellierung Heidelberg Berlin Spektrum Akademischer Ver lag 1998 3 BOEHM B A spiral model of software development and enhancement In ACM SIGSOFT 1986 S 14 24 4 FLEISCHER A Ist Qualit t messbar In Java Magazin 5 2008 S 99 104 5 HAREL D FELDMAN Y Algorithmik Die Kunst des Rechnens Berlin Heidelberg Springer Verlag 2006 6 HINDEL B H RMANN K M LLER M SCHMIED J Basiswissen Software Projekt management Heidelberg dpunkt verlag 2009 7 RAYMOND E S The cathedral and the bazaar In First Monday 3 1998 Nr 3 http www uic edu htbin cgiwrap bin ojs index php fm article view 578 499 8 ROBLES G A Software Engineering approach to Libre Software In GEHRING R A Hrsg LUTTERBECK B Hrsg Open Source Jahrbuch 2004 Zwischen Software entwicklung und Gesellschaftsmodell Berlin Lehmanns Media LOB de 2004 ISBN 978 3 93642 778 3 S 193 208 http www opensourcejahrbuch de 2004 pdfs 111 3 Robles pdf 9 SCHNEIDER K Abenteuer Software Qualit t Grundlagen und Verfahren f r Qualit tssi cherung und Qualit tsmanagement 1 Heidelberg dpunkt verlag 2007 10 SEEMAN J VON GUDENBERG J Software En
55. l ufe k nnen Sequenzen von sol chen Oberfl chenskizzen Storyboards hnlich einem Comic Strip erstellt werden Bei einem Funktionsprototyp vertikaler Prototyp dagegen wird ein Ausschnitt der geforderten Funktio nalit t realisiert der alle Schichten der Software berdeckt beispielsweise von der Benutze roberfl che bis zur Datenbankanbindung zur berpr fung bestimmter Anforderungen an die Performanz einer Stammdatenverwaltung H ufig werden Prototypen im Rapid Prototyping realisiert also quick and dirty um sich schnell Klarheit ber einen bestimmten Aspekt zu verschaffen und Aufwand zu sparen Man kann den Prototyp beim bergang zum Entwurf wegwerfen Wegwerfprototyp oder aber weiterentwickeln und in das Endprodukt einflie en lassen Untersuchungen deuten darauf hin dass die Qualit t des Endprodukts bei Wegwerfprototypen h her ist 5 22 2 1 Softwareentwicklung als Projekt 2 1 1 Das Wasserfallmodell Das einfachste und grundlegenste Vorgehensmodell ist das Wasserfallmodell Ihm gem werden die oben genannten Phasen der Softwareentwicklung streng nacheinander abgear beitet Abb 2 1 Dem Wasserfallmodell unterliegt die Grundannahme dass die Erstellung Anforderungs definition Analyse u Entwurf Implementierung Po Funktions pr fung Installation und Wartung Abbildung 2 1 Das Wasserfallmodell der Software ein Projekt
56. len Matrizen der Funktionskomplexit ten function complexity matrices zu David Longstreet Function Points Analysis Training Course Online Tutorial 46 http www softwaremetrics com freemanual htm Letzter Abruf 16 2 2008 Eingaben Anzahl Datenelemente Ausgaben amp Anzahl Datenelemente Abfragen Datentypen lt 5 5 15 gt 15 Datentypen lt 6 6 19 gt 19 1 einfach einfach mittel 1 einfach einfach mittel 2 einfach mittel komplex 2 3 einfach mittel komplex gt 2 mittel komplex komplex gt 3 mittel komplex komplex Datenbest nde amp Anzahl Datenelemente Schnittstellendaten Datentypen lt 20 20 50 gt 50 1 einfach einfach mittel 2 5 einfach mittel komplex gt 5 mittel komplex komplex Die Addition der einzelnen Funktionspunkte ergibt dann die ungewichteten Funktions punkte unadjusted function points insgesamt des Softwaresystems Kategorie Komplexit t Gesamt einfach mittel komplex Eingaben 3 4 6 Ausgaben 4 5 7 Abfragen 3 4 6 Datenbest nde 7 10 15 Schnittstellen _ 5 T 10 Ungewichtete Funktionspunkte Als letztes gewichtet man diese mit Bewertungsfaktoren die technische Einflussfaktoren widerspiegeln Insgesamt ergibt sich damit das Bewertungsformular der Funktionspunkt analye in Abb Kategorie Anzahl Komplexit t
57. ls die Meinung eines einzelnen zuf llig aus dieser Masse gew hlten Experten e Friihe und schnelle Releases Die erste Version der Software sollte so fr h wie m glich ver ffentlicht werden so dass sehr fr h Ko Entwickler gefunden werden e Regelm ige Integration Neuer Code sollte so oft wie m glich integriert werden um einen berhang zu vieler zu behebender Bugs am Ende des Entwicklungszyklus zu vermeiden Einige Open Source Projekte haben nightly builds deren Integration t g lich automatisiert durchgef hrt wird e Mehrere Versionen Es sollte stets zwei Versionen der Software geben eine Betaversi on oder Entwicklerversion mit mehr Features und eine stabilere Version mit weniger Features Die Entwicklerversion ist f r Anwender bestimmt die die neuesten Featu res sofort verwenden wollen und bereit sind die Risiken zu tragen die der Gebrauch von noch nicht gr ndlich getestetem Code in sich birgt Die Anwender k nnen dann als Ko Entwickler agieren Bugs melden und Bugs fixen Die stabile Version dagegen enth lt weniger Bugs und weniger Funktionalit ten e Hohe Modularisierung Die allgemeine Struktur der Software sollte modular sein um parallele Entwicklung zu erm glichen e Dynamische Struktur zur Entscheidungsfindung Es muss eine Struktur zur Entscheidungs findung vorhanden sein formell oder informell um strategische Entscheidungen auf grund sich ver ndernder Anwenderanforderungen oder anderer Faktoren zu tref
58. mal y Eine Qualit tsanforderung ist eine Menge von zusammengeh ri gen Qualit tszielen Wenn man die gew nschte Auspr gung von Qualit tsmerkmalen angeben m chte ben tigt man Qualit tsmetriken Das sind Ma e Wertebereiche von bis oder Indikatoren trifft zu oder trifft nicht zu f r bestimmte Qualit tsmerkmale Beispielsweise besteht die Qualit tsanforderung hohe Verf gbarkeit des Rechnersys tems aus den Qualit tszielen Robustheit bei vielen Internetzugriffen ausreichende Ge schwindigkeit bei hoher Netzlast und einfachen Benutzeroberfl chen d h Robustheit Ge schwindigkeit und Gestaltung der Benutzeroberfl chen sind die Qualit tsmerkmale Die entsprechenden Qualit tsmetriken k nnten dann die Anzahl paralleler Benutzer gegen die das System robust sein soll die Anzahl der Operationen pro Sekunde f r die Geschwindig keit Um Qualit tsanforderungen vern nftig zu erheben und zu pr fen sind wie in ande ren Bereichen des Qualit tsmanagements Wokshops und Mitarbeiterbefragungen Abstim mungsrunden und Validierungen erforderlich Man kommt dabei oft relativ schnell zu allge meinen vagen Qualit tsanforderungen der schwierigste Teil der Arbeit besteht darin diese auf Qualit tsmerkmale und Qualit tsziele und schlie lich auf ihre Qualit tmetriken zu kon kretisieren Meist versucht man schrittweise dahin zu gelangen mit Hilfe eines sogenannten Qualit tsmodells das modelli
59. metriken und wird typischerweise verwendet um den Aufwand f r die Entwicklung eines Programms zu prognostizieren oder um Programmieraufwand oder Softwareproduktivit t zu sch tzen LOC ist eine Quantit tsmetrik Diese Softwaremetrik ist scheinbar sehr einfach man muss ja nur die Zeilen z hlen Al lerdings beginnen hier die Schwierigkeiten Was ist denn eigentlich zu z hlen Je nach Defi nition z hlt man e nur Zeilen in denen ausf hrbare Programmteile stehen e auch Kommentarzeilen e auch Leerzeilen dazwischen Zus tzlich muss bei jeder Variante genau festgelegt sein e Wie z hlt man Anweisungen die sich ber mehrere Zeilen erstrecken wie Verzwei gungen oder Schleifen IT DeMarco Controlling Software Projects Management Measurement and Estimation ISBN 0 13 171711 1 40 e Werden auch Zeilen gez hlt die nur Klammern oder Blockbefehle enthalten e Was ist wenn in einer Zeile mehrere Befehle stehen Je nach Definition wird ein und dasselbe Quelltextfragment gemessen in LOC k rzer oder l nger Das Programm in Abb 6 1 hat 13 Zeilen inklusive einer Leerzeile Ohne Blockbefehl public void kaufeTicket Kommentarzeile Erwachsene zahlen mehr Zeile mit Anweisung if isAdult Kommentarzeile hier wird bezahlt Zeile mit Anweisung payFullFee x else alle anderen zahlen weniger pay ReducedFee auf jeden Fall Ticket drucken printTi
60. mmierern Das Mo dell zeichnet sich durch die folgenden Eigenschaften aus 7 8 e Anwender werden als Ko Entwickler behandelt D h sie haben Zugriff auf den Quelltext und werden ermutigt Erweiterungen der Software Fehlermeldung bug report Feh lerbehebungen bug fix Dokumentation usw vorzulegen Je mehr Ko Entwickler in volviert sind desto schneller werden die Entwicklungszyklen der Software Das Ge setz von Linus besagt Gen gend viele Tester finden jeden Softwarefehler und zu jedem einmal erkannten Problem gibt es einen Entwickler der es l stP Durch die breite Basis und die Kommunikation ber das Internet k nnen die beiden zentralen Aktionen eines Zyklus im Basarmodell Bug Reporting und Bug Fixing sehr schnell und zahlreich ab laufen Here I think is the core difference underlying the cathedral builder and bazaar styles In the cathedral builder view of programming bugs and development pro blems are tricky insidious deep phenomena It takes months of scrutiny by a de dicated few to develop confidence that you ve winkled them all out Thus the long http www eclipse org epf Letzter Abruf 17 3 2008 Somebody finds the problem and somebody else understands it Finding it is the bigger challenge Linus Torvalds 7 20 release intervals and the inevitable disappointment when long awaited releases are not perfect In the bazaar view on the other hand you assume that bugs are generally sh
61. mt 8380 Projekte ber cksichtigt 2004 insgesamt 9 236 Projekte Die Ergebnisse sind in Tab dargestellt Ferner zeigte sich 2004 dass nur 4 der Projekte sich mit dem Kauf kompletter Anwendungssysteme ohne weitere Anpassungen befassten alle anderen stell ten Anpassungen 13 Komponentenerstellung 22 oder gar Neuentwicklungen 55 davon objektorientiert 19 dar 1 2 Ursachen The major cause of the software crisis is that the machines have become several orders of magnitude more powerful To put it quite bluntly as long as there were no machines programming was no problem at all when we had a few weak computers pro gramming became a mild problem and now we have gigantic computers programming has become an equally gigantic problem Edsger Dijkstra 1972 Allen Problemf llen der Softwarekrise gemeinsam ist die Komplexit t der betreffenden Pro gramme Nat rlich gibt es einen gro en Unterschied zwischen Programmieraufgaben die Sie im Laufe der ersten Semester zu l sen hatten und Programmierprojekten bei denen es um Millionen Zeilen Quelltext geht So geh ren moderne Betriebssysteme zu den kom plexesten Produkten die Menschen jemals erschaffen haben Ein so gro er quantitativer Unterschied bewirkt entsprechend einen qualitativen Unterschied in der Komplexit t und erfordert eine vollkommen neue Handhabung Eine einzelne Person kann vielleicht noch alle oder wenigstens wesentliche Details eines kleinen Problems bersch
62. mtzahl verschiedener Operatoren nz Gesamtzahl verschiedener Operanden Halstead Ma e Programml nge N N N2 Programmvokabular n n n2 Halstead Volumen V N Na log n n2 Halstead Schwierigkeitssgrad o 2 Halstead Aufwand E V D Intelligenzgehalt I V D gesch tzte Fehlerzahl B V 3000 Abbildung 6 2 Formeln f r Halstead Ma e rator etwa x aber auch ein Anweisungstrenner Operanden sind u a Literale Konstanten und Variablen Als Daumenregel hat sich die Fehlerformel bew hrt allerdings steckt eine gewisse Ge fahr in der Optimierung des Quelltexts bez glich dieser Kennzahl Man kann das Hal stead Volumen des Programms verkleinern indem man dieselbe Variable f r mehrere Be rechnungen verwendet das kann sinnvoll sein z B stets i j k als Schleifenindizes zu ver wenden ist aber per se kein Selbstzweck denn durch sinnvolle Namensgebung wird der Quelltext lesbarer und verstehbarer Empirisch gilt die Halstead sche L ngengleichung N x n log n n2 log n2 Nach einer Theorie des Psychologen John Stroud ist ein Moment definiert als diejenige Zeit spanne die das menschliche Gehirn f r die elementarste Unterscheidungsoperation discri mination ben tigt Die Stroud Zahl S ist entsprechend die Anzahl der Momente pro Sekunde F r die meisten Menschen gilt 5 lt S lt 20 S hat die Einheit einer Frequenz Hz sec Mit der Stroud Zahl ergibt
63. n Customi zing an die unterschiedlichen Bed rfnisse der Anwender angepasst werden kann z B Finanzbuchhaltungs oder Warenwirtschaftssysteme oder Office Programme f r Textver arbeitung und Tabellenkalkulation iv Oft steuern Anwendungssysteme technische Prozesse Fertigungsstra en Flug berwa chung mit sog eingebetteten Systemen embedded systems wie Motormanagement im Auto mobil oder Steuerung des DVD Players wird die Grenze zur an sich nicht mehr unter dem Begriff der Anwendungssoftware fallenden Systemsoftware wie Betriebssysteme oder Daten banken berschritten die sich keinem bestimmten Anwendungsbereich zuordnen l sst Nat rlich befasst sich das Software Engineering im Allgemeinen mit dem Herstellungs prozess jedweder Software ohne Unterschied zwischen Anwendungs oder Systemsoftwa re Allerdings wird der Schwerpunkt der beruflichen T tigkeit vorwiegend auf Anwen dungssoftware liegen wahrscheinlich allen Folgen der Globalisierung zum Trotz System software auch Standardsoftware kann auch in L ndern mit billigerer Lohnstruktur und ge n gend hohem Bildungsniveau ausgef hrt werden die Konfiguration oder Erstellung von Anwendungssoftware wird auch in Zukunft die Kenntnis der lokalen wirtschaftlichen ju ristischen und soziokulturellen Hintergr nde erfordern Und der Bedarf an Anwendungs entwicklung ist heute schon hoch er wird zuk nftig sicherlich steigen Hagen den 3 Januar 2011 Andreas de Vries Kap
64. nagers eintreten und bereits erreichte Meilensteine revidiert werden und erneut zu erlangen sind Jede Softwareentwicklung bewegt sich im Spannungsfeld dieses Zielkonflikts zwischen Plan und Budgetierbarkeit einerseits und Anforderungserf llung und Qualit t anderer seits Die folgenden Abschnitte beschreiben Ans tze zu realisierbaren L sungen dieses Ziel konflikts 14 2 1 2 Das V Modell Projektmanagement und Qualit tssicherung Das V Modell entstand in den 1980er Jahren aus dem Wasserfallmodell und legt verst rkten Wert auf Qualit tssicherung Zu jeder Phase des Projekts werden entsprechende Testphasen definiert sowohl die Anforderungs bzw Entwurfsspezifikationen verifizieren als auch die vorgesehene Nutzbarkeit der Produkte validieren Die Verifikation hinterfragt also Wurde Verifikation System if Systemtest anforderung Validierung Systementwurf Integrationstest N Modulentwurf e Unittest T Implementierung Abbildung 2 3 Das V Modell das Produkt richtig entwickelt die Validierung dagegen Wurde das richtige Produkt entwi ckelt Im Unterschied zum Wasserfallmodell werden Testf lle nicht erst gegen Ende des Pro jekts spezifiziert sondern bereits dann wenn die Anforderungs bzw Entwurfsspezifikatio nen fertig gestellt sind In der Abbildung 2 3 bedeutet das dass die Testf lle nicht erst im rechten Ast er
65. nd andererseits bei den Entwickler keine Kenntnisse aus dem Anwendungsbereich ist die Hauptaufgabe der Anforderungsdefinition die Kl rung der Anforderungen und im tieferen Sinne Auf bau und Aufrechterhaltung von Kommunikation und Wissensermittlung Manche Software wird angebotsorientiert erstellt also ohne einen individuellen Kun den im Sinn Beispiele daf r sind kommerzielle Softwareprodukte wie ERP Systeme 11 Betriebssysteme oder Spielesoftware In diesen F llen werden die Kundenbed rfnisse antizipiert e Analyse oft auch Anforderungsspezifikation In dieser Phase werden die Ergebnisse der Anforderungsdefinition m glichst exakt festgeschrieben Die Spezifikation oder das Pflichtenheft soll nur beinhalten warum die Software erstellt wird und was sie leisten soll und das m glichst pr zise nicht aber wie sie es schaffen soll Grundproblem der Analyse ist dass sie zwei gegens tzliche Ziele erf llen soll Auf der einen Seite muss sie informell intuitiv und f r Nicht Informatiker verst ndlich sein damit der Kunde validieren kann Wir erstellen das richtige Produkt Auf der an deren Seite muss sie pr zise genug sein damit Entwickler und Tester stets verifizieren k nnen Wir erstellen das Produkt richtig e Entwurf In diesem Prozess wird das Problem in Module zerlegt und geeignete Algo rithmen und Datenstrukturen ermittelt und modelliert Hierzu ist ein tiefes algorith misches Verst ndnis notwendig
66. nes solchen Systems ist also entweder eine Client Server Architektur wo der Server alle aktu ellen Dateien und deren Historie speichert und die Clients sich alle Dateien kopieren und lokal entwickeln Oder aber eine Host Struktur wo der Host alle Dateien speichert und die Entwickler an blo en Terminals arbeiten Alle g ngigen Verwaltungssysteme funktionieren nach dem Client Server Prinzip In beiden Varianten m ssen die neuen Versionen der Da teien nach den gew nschten nderungen auf den Server zur ck gespeichert werden Dabei kann es zu Konflikten kommen wenn simultan von anderen Entwicklern schon nderun gen der Dateien vorgenommen wurden die von dem System angezeigt werden m ssen 5 1 1 Merge Der Vorgang des Abgleichens mehrerer nderungen die an verschiedenen Versionen der selben Dateien get tigt wurden heift Mergd Das Ergebnis eines Merge Vorgangs ist eine einzige Datei die alle Aspekte der verschiedenen Datei Versionen vereinigt In vielen F llen gelingt der Merge Vorgang automatisch ohne menschliche Interaktion Werden jedoch ver schiedene nderungen zusammengef hrt die den gleichen Abschnitt einer Datei betreffen so kommt es zu einem Merge Konflikt Dieser kann nur manuell aufgel st werden lo merge vereinigen zusammenf hren 34 5 1 2 Branching Trunk und Fork Die Verdopplung eines Objekts beispielsweise einer Quelltextdatei oder ein Verzeichnis baum hei t in der Versionsverwaltung revision co
67. ntrol und dem Softwarekonfigurations management Branching Die separate Weiterentwicklung beider Zweige branch geschieht nun parallel Nach einem Branching ist es m glich die beiden Zweige wieder zusammen zuf hren merge Beachten Sie dass ein Merge von Entwicklungszweigen nderungen auf der Projektmanagementebene bewirkt w hrend der Merge zweier Quelltextdateien sich zu n chst nur auf der Programmierebene abspielt technisch sind beides freilich gleiche Prozes se branch ERR fork DD O T O Abbildung 5 1 Versionen durch Branch Merge und Fork eines Projektes Ein spezieller Zweig der Trunk oder HEAD ist der Hauptzweig des Systems Er enth lt blicherweise die aktuelle stabile Verson des Systems Oft wird diese verzweigt und etwaige Bug Fixes werden von Zweigen in den Trunk zusammengef hrt Jeder Zweig kann mit dem Trunk zusammengef hrt werden auch wenn er nicht der Flternzweig ist Wird bei einem Branching von vornherein ein Merge nicht beabsichtigt so spricht man von einem Fork oder einer Projekt Abspaltung Ein Fork ist also ein Entwicklungszweig bei dem Teile des Projektes oder das gesamte Projekt kopiert werden und unabh ngig wei terentwickelt werden Ein solcher Fall liegt vor wenn beispielsweise die bisherige Software einem neuen Zweck angepasst wird oder es neue Lizenzmodelle f r den Zweig geben soll Bekannte Projekte die aus Forks entstanden sind sind Firefox und Thunderbird aus dem Mozilla Projekt O
68. ommit am Repository ge ndert wurde Beispielsweise k nnte eine Datei bei der Revision 25 zum Projektarchiv hinzugef gt wor o a os 8 merge 5 Abbildung 5 4 Revisionen und das Tag und Branch Konzept von Subversion den sein und einmal in der Revision 48 und 52 ver ndert worden sein Bei einem Checkout http subversion tigris org frei ist hier im selben Sinne wie in freie Rede zu verstehen aber nicht wie in Freibier 11 Freie Software ist ohne Beschr nkungen zu benutzen und ist nicht nur kostenlos 38 einer Datei wird die gr te Revisionsnummer ausgecheckt die kleiner oder gleich der ange forderten ist Wird in dem Beispiel die Revision 52 angefordert so wird die Revision 52 der Datei ausgecheckt wird hingegen die Revision 51 angefordert liefert Subversion die Inhalte von Revision 48 5 3 2 Tag und Branch Konzept von SVN W hrend Tags und Branches in CVS eine klar definierte Bedeutung haben kennt Subversion nur das Konzept der Kopie die je nach Nutzungsart einen Tag oder Branch Charakter haben kann Jede Kopie einer Datei oder eines Verzeichnisses ist in Subversion demnach automa tisch ein Branch dieser Datei oder des Verzeichnisses Tags entstehen in Subversion wenn man eine Kopie anlegt und sp ter auf ihr keine nderungen mehr vornimmt Aufgrund des Fehlens einer Tag und Branch Semantik muss die Strukturierung und Verwaltung von Tags und Branches der Benutzer und
69. onzeption incep tion Ausarbeitung elaboration Konstruktion construction und bergang in den Betrieb tran sition wie in Abb P 6 illustriert Je gr er dabei die Fl che unter der Kurve innerhalb einer Phase ist desto umfangreicher sind die in der entsprechenden Disziplin durchzuf hrenden Aktivit ten Insbesondere am Ende der Ausarbeitungsphase liegt ein ausf hrbarer Prototyp der Entwurfspezifikation vor nach der Konstruktionsphase die Beta Version des Systems Die Phasen des RUP sind jeweils wieder durch Iterationen unterteilt und wie in einer Phase werden innerhalb einer Iteration praktisch alle Disziplinen durchlaufen mit dem Ziel jeweils eine ausf hrbare Zwischenversion des Systems zu erhalten bis schlie lich das beim Anwender einzusetzende System vorliegt Trotz der prinzipiellen Unterschiede zum Wasserfallmodell zielt auch der RUP darauf ab die Anforderungen nach einer angemessenen Zeit am Ende der Ausarbeitungsphase vorliegen zu haben Auch der Entwurf sollte zu Beginn der Konstruktionsphase weitest gehend abgeschlossen sein Auch wenn die starren Abgrenzungen der Phasen des Wasser fallmodells beim RUP nicht vorliegen werden sich Anforderung und Entwurf beim RUP idealtypisch nicht in nennenswertem Umfang in die sp teren Phasen hineinziehen 19 2 2 4 Das Eclipse Process Framework EPF The Eclipse Process Framework EPF Mis an open source project that is managed by the Eclipse Foundation It lies under the
70. osten Fehlerkosten Qualit tsaufwand Abbildung 7 1 Optimierung der Qualit tsaufw nde Die Fehlerkosten umfassen beispielsweise Kosten f r R ckrufaktionen oder Reparaturen an Qualit t erlangt und der Anbieter daf r ein Minimum an Qualit tskosten hat Entspre chend kann das Ziel einer Qualit tssicherung nicht sein die Qualit t auf perfektes Niveau zu bringen sondern die vom Nachfrager erwartete Qualit t zu garantieren 7 3 Systematisches Testen Die Qualit tssicherung von Software bedient sich einiger grundlegender Verfahren Dazu geh rt die Usability also die Pr fung der Bedienbarkeit und der Gebrauchstauglichkeit von Software beispiesweise die Abstimmung der Bedienabl ufe und die Gestaltung des gesam ten Programms nicht nur der Bedienoberfl che auf die Anwender und ihre Aufgaben Wei tere wichtige Verfahren der Qualit tssicherung sind das Testen und Reviews Definition 7 2 Testen ist die Ausf hrung von Software mit dem Ziel Fehler zu finden Diese Definition impliziert dass durch Testen m glichst viele schwere Fehler zu finden sind Ein Abnahmetest also eine Menge zwischen Auftraggeber und Auftragnehmer verein barter Pr ff lle denen die Software bei der bergabe unterzogen wird geh rt damit in diesem Sinne gar nicht zum Testen Die Zielsetzung eines Abnahmetests ist es n mlich tat s chlich festzustellen dass die Software das Vereinbarte leistet also genau entgegengesetzt zur Ab
71. penOffice aus StarOffice aMuke aus xMule oder das NTSF Dateisystem aus HPFS dem Dateisystem von OS 2 Voraussetzung f r ein funktionierendes Verzweigen und Zusammenf hren ist eine aus reichende Modularit t der Software und eine gen gend klare funktionale Abstimmung der Entwicklungsstr nge Wenn in Abb P 1 beispielsweise Version 1 2 1 1 wesentlich auf Funk tionen der Version 1 2 aufbaut die aber in Version 1 3 ver ndert wurden wird ein Zusam menf hren wom glich inhaltlich nicht mehr m glich sein da die neue Funktion zu Fehlern in 1 2 1 2 f hrt Im schlimmsten Fall kann der Konflikt nur gel st werden indem man die Teilprojekte abspaltet 5 2 CVS Concurrent Versions System CVS auch Concurrent Versioning System ist ein Software System zur Versionsverwaltung von Dateien insbesondere von Software Quelltext Es h lt alle n derungen einer gegebenen Menge von Dateien vor und erm glicht so kollaborative Ent wicklung Ein durch CVS verwaltetes Projekt heift Modul module CVS hat eine Client Server Architektur Alle Dateien eines Softwareprojektes werden an einer zentralen Stelle dem Repository gespeichert Dabei k nnen jederzeit einzelne Datei en ver ndert werden es bleiben jedoch alle fr heren Versionen erhalten stets einsehbar und wiederherstellbar Auch k nnen die Unterschiede zwischen verschiedenen Versionen angezeigt werden und so ein berblick ber die einzelnen Versionen der Dateien und der dazugeh rigen Komm
72. r Klasse bestimmt und daraus den WMC der ganzen Klasse berechnet Wird der WMC zu gro so wird er Methoden in neue Klassen auslagern und ihn somit vermindern Per se ist das allerdings nicht unbedingt eine gute Strategie denn so k nnen fachlich zusammenh ngende Methoden unn tig zerschla gen werden Als Beispiel m ge hier die Klasse math der Java SE API dienen die in sehr sinnvoller Weise g ngige mathematische Funktionen in wenn auch statische Methoden zusammenfasst und somit einen sehr hohen WMC haben d rfte 6 3 2 DIT DIT depth of inheritance tree 4 ist f r eine gegebene Klasse definiert als ihre Tiefe im Verer bungsbaum d h in welcher Generation sie von einer Klasse erbt die von einer Klasse erbt die von einer Klasse erbt Eine hohe Vererbungstiefe spricht prinzipiell f r eine h here Fehleranf lligkeit denn von jeder vererbenden Klasse werden eben auch noch unentdeckte Bugs geerbt DIT ist somit ein Ma f r die Wiederverwendbarkeit im System In Java wo jede Klasse von der Klasse object erbt ist der Wert von DIT mindestens 1 6 3 3 NOC NOC number of children 4 ist als die Anzahl der direkten Unterklassen der betrachteten Klasse definiert Sie kann einerseits den Grad an Wiederverwendbarkeit messen aber auch ein Indikator f r eine bertriebene Verwendung von Vererbung sein hnlich wie bei PtDIT 43 gilt dass eine hohe Anzahl von Unterklassen durch Vererbung unentdeckter Bugs eine hohe Fehleranf ll
73. r Menge von Aufgaben und Verantwortlichkeiten im Rahmen eines Projekts oder einer Organisation Insgesamt m ssen die in Abbildung 2 8 aufgef hr ten Beziehungen eingehalten werden Im Mittelpunkt der Vorgehensbausteine stehen die beinhaltet beinhaltet 4 1 1 1 bearbeitet k x 4 verantwortet 1 m nn X i ll Rolle h ngt ab von Abbildung 2 8 Ein Vorgehensbaustein im V Modell XT bildet sich aus Aktivit ten Produkten und Rollen und ihren Beziehungen untereinander Grafik nach 6 82 4 Arbeitsergebnisse die Produkte Ein Produkt kann aus mehreren untergeordneten Produk ten bestehen au erdem k nnen Abh ngigkeiten zwischen Produkten existieren Eine Rolle ist verantwortlich f r Produkte und Produkte werden durch Aktivit ten bearbeitet Aktivi t ten k nnen wieder in weitere Aktivit ten unterteilt werden Vorgehensbausteine k nnen eigenst ndig verwendet werden wobei gegebenenfalls Abh ngigkeiten zu anderen Vorge hensbausteinen zu ber cksichtigen sind Vorgehensbausteine legen keine konkrete Reihenfolge im Projekt fest Dies geschieht durch die Projektdurchf hrungsstrategien Abbildung Sie legen die Reihenfolge von zu Projekt durchf hrungs legt Reihenfolge fest 1 N Entscheidungs ben tigt 1 punkt 1 E Produkt Strategie Abbildung 2 9 Durchf hrungsstrategien im V Modell XT Grafik nach 6 82 4 erreichenden Projektstu
74. r zwischen der aktuell in Entwickelung befindlichen Betaversion mit neuen aber wom glich fehlerhaften Funktionen oder einer alten stabilen Version w hlen konnten Linux was the first project to make a conscious and successful effort to use the entire world as its talent pool I don t think it s a coincidence that the gestation period of Linux coincided with the birth of the World Wide Web and that Linux left its infancy during the same period in 1993 1994 that saw the takeoff of the ISP industry and the explosion of mainstream interest in the Internet Linus was the first person who learned how to play by the new rules that pervasive Internet made possible Eric S Raymond Nach Richard Stallman dem Gr nder der GNU Public License und der Bewegung f r Freie Software ging mit der Entstehung von Open Source ein Paradigmenwechsel einher indem die Freiheit von Software als Grundsatz ausgetauscht wurde durch die Effizienz der Entwick lung von Software 11 2 3 Psychologie des Software Engineering Neben standardisierten Methoden oder Daumenregeln des Software Engineering die die Effizienz der Softwareentwicklung steigern gibt es einen weiteren Faktor die Software Analytiker Entwickler und Manager als Menschen mit all ihren St rken und Schw chen Nach einer bekannten Anekdote 5 S 428ff befand sich an einem Ende eines gro en Rech nerraum f r Studenten in einer Universit t ein Getr nkeautomat Nachdem es von einigen Studenten Besch
75. rik muss so gestaltet sein dass die Optimierung ihrer Kennzahl zu einem w nschenswerten Ergebnis f hrt Eine Metrik wirkt auf diese Weise handlungsleitend und wenn sie das Richtige misst f hren die durch sie beeinflussten Handlungen zum Erfolg des Projekts Was also so unscheinbar mit einer kleinen Routine zur Messung von Leistung begonnen hat ver ndert nun die Software qualit t hier beispielsweise den Qualit tsaspekt Verstehbarkeit durch mehr Kommentare Weitere Quantit tsmetriken sind beispielsweise DOC inline documentation lines of code das die Anzahl Zeilen von Inline Dokumentation wiedergibt oder NCSS non commenting source statements das die Anzahl der effektiven Programmanweisungen misst F r Java sind dies vereinfacht diejenigen Zeilen in denen eine ffnende geschweifte Klammer oder ein Semikolon steht 41 6 2 Zyklomatische Komplexit t von McCabe Von McCabe stammt eine etwas komplizierte Metrik 9 84 3 2 die zyklomatische Komplexit t CCN cylomatic complexity number oder McCabe Metrik von Thomas McCabe 1976 einge f hrt Anders als LOC ist sie genau definiert Der Ausdruck Komplexit t sagt aus was gemessen werden soll n mlich wie kompliziert die untersuchte Software strukturiert ist Die Metrik erh lt ein Quelltextfragment und liefert eine nat rliche Zahl Zum Verst ndnis der zyklomatischen Komplexit t muss man sich McCabes Vorstellung von struktureller Schwierigkeit verdeutlichen Ein
76. rung w chst h ufig erst das Verst ndnis f r das Problem Somit gibt es h ufig und gerade bei neuar tigen und innovativen Systemen falsche Entscheidungen in den ersten Phasen die sp ter korrigiert werden m ssen L st man jedoch das Prinzip der Unumkehrbarkeit der Phasen entscheidungen auf so wird das Projekt schlechter planbar und ein anf nglich angesetztes Budget kann schnell aus dem Ruder laufen Das Wasserfallmodell eignet sich also besonders wenn die Entwickler eine hinrei chend genaue Vorstellung des Problembereichs haben beispielsweise wenn ein erfahrenes Softwareteam ein neues Produkt ausarbeitet das so hnlich ist wie eines das sie bereits zu vor entwickelt haben Bei besonders innovativen oder einfach noch nicht hinreichend gut verstandenen Systemen dagegen ist das Wasserfallmodell eher ungeeignet Das modifizierte Wasserfallmodell war eine fr he recht naheliegende Anpassung des Vor gehensmodells an diese Schwierigkeiten Abbildung 2 2 Es erm glicht die R ckkopplung Anforderungs definition i Analyse Entwurf gt Implementierung Po Funktions pr fung Installation und Wartung Abbildung 2 2 Das modifizierte Wasserfallmodell zumindest zur jeweils n chstfr heren Phase falls Fehler aufgetreten sind Wird dieses Vor gehensmodell konsequent eingesetzt so kann schlimmstenfalls der Albtraum eines klassi schen Projektma
77. s Vorgehensmodell denn es gibt nicht notwendig ein von Beginn an festgelegtes Ende Die Ziele f r jeden Zyklus werden aus den Ergebnissen des vorherigen Zyklus abgeleitet es gibt auch keine Trennung zwischen Wartung und Entwicklung 2 2 2 Versionen Entwicklung Versioning Eng verwandt mit dem Spiralmodell ist der Ansatz des Versioning der auch als evolution res Modell oder Prototyping bezeichnet wird S 120f Allerdings ist es nicht risikogetrieben wie das urspr ngliche Spiralmodell sondern code getrieben d h Priorit t haben jeweils lauff hige Teilprodukte Eine Variante des Versioning ist das inkrementelle Modell Der Unterschied zum Versio ning ist nach Balzert dass hier schon zu Beginn die Anforderungen an das Produkt voll st ndig erfasst werden Allerdings werden dann hnlich wie beim Versioning Teilsysteme bzw Ausbaustufen entworfen und implementiert 2 2 3 Der Rational Unified Process RUP Der Rational Unified Process RUP ist ein objektorientiertes inkrementelles Vorgehensmodell zur Softwareentwicklung und ein kommerzielles Produkt der Firma Rational Software die seit 2002 Teil des IBM Konzerns ist Der RUP benutzt die UML Unified Modeling Langua ge vgl als Notationssprache Der RUP sieht verschiedene Disziplinen disciplines vor welche die zu Beginn dieses Kapitels aufgef hrten Phasen der Softwareentwicklung etwas variieren und fachlich inhaltlich strukturieren 83 3 e Bei der Gesch ftsprozessmodellierung
78. s ihres aktuellen Zustands zu erstellen In CVS wird eine Resource versioniert indem man sie mit einem Version Tag versieht Eine so versionierte Resource wird unver nderlich im Repository gespeichert und ist damit auch sp ter immer wieder reproduzierbar Es gibt in CVS zwei M glichkeiten eine Version einer Resource zu erstellen n mlich einerseits im lokalen Workspace und danach mit commit im Repsoitory oder direkt in ei nem Branch im Repository Wird eine Resource im Workspace versioniert so werden auch nur die lokal enthaltenen Resourcen markiert w hrend bei Versionierung in einem Branch alle zu diesem Zeitpunkt darin enthaltenen Dateien versioniert werden Die blicherweise durchgef hrte Versionierung ist diejenige vom Workspace aus 37 5 3 Subversion Subversion SVN ist eine Open Source Software zur Versionsverwaltung von Dateien und Verzeichnissen Sie steht unter einer Apache BSD artigen Lizenz und ist damit freie Soft ware Es funktioniert im Wesentlichen wie CVS insbesondere der Arbeitsablauf ist gleich Abb 5 3 Subversion wurde entwickelt einige Schw chen von CVS zu beheben Da CVS in Entwicklerkreisen sehr verbreitet war und ist ist es mit Bedacht in der Bedienung sehr hnlich gehalten Ein entscheidender Unterschied zwischen CVS und SVN liegt in der Rangfolge von rt licher L und zeitlicher T Kennzeichnung der Inhalte eines Projektarchivs P w hrend in CVS prim r rtlich sekund r zeitlich adressiert
79. sich ndern Definition 7 3 Ein Fehler einer Software ist die Abweichung der Software von dem in der Spezifikation vorgeschriebenen Verhalten Folglich gilt automatisch Keine Spezifikation keine Fehler Stellt man beim Testen fest dass ein Resultat Ist nicht mit dem erwarteten Wert Soll bereinstimmt muss nicht notwendigerweise ein Softwarefehler der Grund sein Die theoretisch m glichen Ursachen lauten Ist Soll Sollwert Ursache Kein Sollwert dokumentiert falsch Anforderung falsch verstanden Sollwert falsch ermittelt Vergleich unangemessen Istwert falsch korrekt Nur im letzten Fall liegt definitiv ein Programmierfehler vor bei allen anderen F llen k nn te die Software sogar korrekt sein der Fehler liegt in den Analyseschritten vor der Imple mentierung Wenn eine Anforderung beim Erstellen der Testf lle falsch verstanden wurde beim Programmieren aber richtig kommt es zu einer Abweichung Die Software ist in Ord nung der Testfall ist falsch Gleiches gilt f r den Fall dass zwar die Anforderung richtig verstanden wurde aber ein Rechenfehler bei der Bestimmung des Sollwerts passierte Es kommt manchmal auch vor dass der Vergleich nicht angemessen oder zu streng ist Wenn komplizierte numerische Algorithmen mit erheblichen Rundungen rechnen kann es sinn voller sein statt eines Sollwerts einen Sollwertbereich anzugeben Das gilt beispielsweise bei Steu
80. sich die Zeit T die ein Mensch zum Verst ndnis eines Quelltextes ben tigt durch die Formel _ 11N gt log n T 23 n log n n2 log n2 6 1 Bei gegebenem Quelltext gilt also T x 1 S d h bei gleichem Quelltext ben tigt ein Mensch mit einer h heren Stroud Frequenz also mehr Momenten pro Sekunde eine l ngere Zeit spanne T als jemand mit einer niedrigeren Stroud Frequenz 6 6 Funktionspunktanalyse Die Funktionspunktanalyse function point analysis ist ein Verfahren zur Bestimmung des fach lich funktionalen Umfangs eines Softwaresystems oder eines Softwareprojektes und ist ein http www sei cmu edu str descriptions halstead html Letzter Abruf 14 4 2008 45 Teilverfahren zur Aufwandssch tzung und Gr enbestimmung von Anforderungen sowie zur Ermittlung von Softwareproduktivit t Der Schwerpunkt der Analyse liegt auf den fach lichen Anforderungen des zu erstellenden Systems Dadurch kann diese Methode schon recht fr h beispielsweise bei Vorlage eines Lastenhefts eingesetzt werden Ein Funktionspunkt wird vergeben f r jedes Datenelement das als Eingabe oder Ausgabe einer Endanwenderfunktion der betrachteten Software ben tigt wird Eine solche Funktion kann beispielsweise eine Datenbankabfrage sein Funktionspunkte werden sin f nf Kate gorien eingeteilt Eingaben inputs Ausgaben outputs Abfragen inquiries Dateien files und Schnittstellendaten interfaces Eingaben interne Datenbest nde
81. sicht des Testen Das Testen entspricht der im Kern sehr ernsten Grundeinstellung von Murphys Gesetz wonach alles was schiefgehen kann irgendwann auch schiefgeht Ein noch verborgener Fehler in einer Software wird irgendwann auftreten Wenn ein Fehler gefunden wurde wei man dadurch noch nicht wie er zustande kam Man wird seine Ursache also nach dem Testen suchen Findet man dagegen keinen Fehler so kann das zweierlei bedeuten Entweder die Software enth lt tats chlich nur wenige oder keine Fehler oder der Test war mangelhaft aufgesetzt so dass er keinen der vorhandenen Fehler gefunden hat Um die zweite unangenehme Ursache auszuschlie en sollte man systematisch testen So werden Fehler zumindest nicht leichtfertig bersehen Herumprobieren gilt daher nicht als Test es kann h chstens die Vorbereitung f r einen richtigen Test sein F r einen systematischen Test kommt es sogar darauf an sich schriftlich vorzubereiten und die Testf lle schriftlich zu dokumentieren Nur so kann man vermeiden von einem plausiblen aber trotzdem falschen Ergebnis geblendet zu werden 7 3 1 Fehler Aber was ist eigentlich ein Fehler Ein Softwarefehler liegt immer dann vor wenn sich die Software falsch verh lt Falsch oder richtig bezieht sich in einem Softwareprojekt immer 50 darauf was in der Spezifikation steht Das ist hoffentlich ziemlich genau das was der Kunde m chte und auch braucht Aber dessen Gedanken k nnen ungenau sein oder
82. sitory O Resource CVS Revision RFC HA RUP 18 Scrum 55 SLOC 40 Software 9 Softwaremetrik Softwarequalit t en Source Lines of Code Sprint 16 a ftware E Story 15 4 Stroud Zahl 45 sTY A Subversion SVN Synchronize Systemsoftware v tailoring 25 a E satiat E Test 19 Testen Testfall Trunk 85 Unicode Usability User Story V Modell V Modell XT Vaina Verifikation Version in CVS Vorgehensbaustein Vorgehensmodell Wasserfallmodell 13 White Box Test 52 ia Wissensmamagement WMC Workbench Workspace XML 30 XP zyklomatische Komplexit t 56
83. stellen entdecken Die Metrik DRY don t repeat yourself 4 berpr ft ob Quelltextstellen doppelt vorhan den sind und kann als Verh ltnis zwischen der Anzahl der Klassen mit Code Duplizierung zu der Anzahl aller Klassen ausgedr ckt werden Es ist damit ein Indikator f r die Wartbar keit und die Wiederverwendbarkeit des Systems Die Einhaltung der Programmierrichtlinien und Quelltextkonventionen wird mit Hilfe der Metrik STY styleness 4 gepr ft Der Messwert kann als Verh ltnis der Anzahl aller Klassen mit Verletzungen der Quelltextkonventionen relativ zu der Anzahl aller Klassen berechnet werden 6 5 Halstead Ma e Die Halstead Software Science ist recht kompliziertes System von Ma en die urspr nglich da zu dienten den Programmieraufwand zu quantifizieren Die Interpretationen der einzel nen Ma e sind allerdings oft unklar daher hat das System heute eher historische Bedeutung Jedoch verwendet man einige der Kennzahlen des Halstead Systems um eine Daumenre gel f r die Anzahl von Fehlern zu gewinnen die in einem Programm gefunden werden Ahttp yunus hacettepe edu tr sencer complexity html Letzter Abruf 14 4 2008 44 sollten Dazu wird die Programml nge N und das Volumen V berechnet und daraus die gesch tzte Fehlerzahl B durch die FormelrP in Abb 6 2 bestimmt Hierbei ist ein Ope Verwendete Variablen primitive Ma e N Gesamtzahl der Operatoren Nz Gesamtzahl der Operanden n Gesa
84. stellt werden sondern bereits im linken 2 1 3 Scrum Scrum Gedr nge ist ein Vorgehensmodell des Projektmanagements das urspr nglich aus Modellen der Produktfertigung der 1980er Jahre stammt und Methoden der Lean Production wie TPS hnelt Die Grundlagen von Scrum liegen im Wissensmanagement Scrum geht von der Grundannahme aus dass Produktions und Entwicklungsprozesse zu komplex sind um sie durch Vorgehensmodelle mit abgeschlossenen Phasen wie das Wasserfallmodell oder das V Modell zu beherrschen Stattdessen geht Scrum davon aus dass es produktiver ist lediglich einen groben Rahmen vorzugeben und das Team sich selbst organisieren zu lassen Scrum kennt die drei Rollen und besteht aus drei Spielphasen 6 82 7 Die Rollen lauten 1 Der Product Owner Er ist er Kunde und legt das gemeinsame Ziel fest das das Team zusammen mit ihm erreichen muss und in den jeweiligen Iterationsschritten die Prio rit ten der entsprechenden Teilprodukt Anforderungen Product Backlogs s u Zur Definition der Ziele dienen ihm User Stories d h in Alltagssprache mit maximal zwei S tzen bewusst kurz gefasste Software Anforderungen oder andere Techniken wie UML Anwendungsf lle 2 Das Team Es besteht idealerweise aus 7 2 Personen sch tzt die Aufw nde der ein zelnen Anforderungen Backlog Elemente ab und implementiert die f r den n chsten Iterationsschritt Sprint s u machbaren Elemente 3 Der Scrum Master Er berwacht die A
85. t t 11 Analyse 12 Analysemetrik Anforderungen 48 Anforderungsdefinition 1 la ee E 12 angebotsorientiert 1 Application cd Mr Basarmodell 20 a H Black Box Test Branching 85 CBO 44 CCN 42 Ce 44 CVS Daily Scrum 16 Deich MERET PT DIT DOC a1 dokumentorientiertes Vorgehensmodell 13 DRY 44 eingebettete Span E Entscheidungspunkt 25 Entwurf 12 19 Erweiterung Software eXtreme Programmierung fachliche Qualit t 48 Fehler Fiskus Softwareprojekt 8 Fork freie Software Funktionspunktanalyse Gesch ftsprozessmodellierung 18 Glass Box Test 52 Halstead Software Science HEAD 35 a 12 19 Inbetriebnahme 1 Individualsoftware iv innere Qualit t 40 Integration 12 JUnit 51 KISS 25 kollaborative Softwareentwicklung LCOM 4 Lines of Code 40 Linux 22 LOC 0 McCabe Metrik 42 Meilenstein 11 25 Merge 34 modifizierte Wasserfallmodell Modul CVS Modularit t Moment Psychologie 45 Murphys Gesetz 50 NCSS 1 NOC 43 Objektmetrik 43 otimistisches Team Modell 36 Paarprogrammierung 23 Patch 12 a Projektdurchf hrungsstrategien 25 Projektmanagement 15 Prototyp 13 Qualit t 48 Qualit t technische 40 Qualit tsmetrik Qualit tsmodell Qualit tssicherung Quantit tsmetrik Rational Unified Process Refactoring Release Repo
86. tenenen Schnittstellen 4 4 Code Konventionen http java sun com docs codeconv 33 Kapitel 5 Kollaborative Softwareentwicklung Die Softwareentwicklung in Teams wird auch kollaborative Softwareentwicklung genannt Die se umfasst insbesondere die Zusammenarbeit mehrerer Entwickler ber ein Netzwerk oder ber das Internet 5 1 Grunds tzliche Problematiken Eine grunds tzliche Problematik kollaborativer Entwicklung ist dass mehrere Entwickler gleichzeitig eine Datei ndern Beim Abspeichern in einem solchen Falle kommt es zu Kon flikten die in der Regel durch eine mit den beteiligten Entwicklern abgesprochene gemein same Versionierung der betroffenen Dateien gel st wird Ein weiteres prinzipielles Problem in der Softwareentwicklung nicht nur der kollabo rativen ist dass man relativ leicht auf eine fr here stabile Version der Software zur ck kommen muss falls durch unbeabsichtigte Fehler oder nicht absehbare Seiteneffekte der aktuellen Entwicklerversion die Software nicht mehr funktioniert Ein automatisches Versionierungssystem welches kollaborative Entwicklung erm glicht muss also den einen aktuellen Versionsstand als auch die vergangenen Versionen Histo rie aller Dateien speichern und bei Abspeicherungen etwaige Konflikte und deren betei ligte Entwickler anzeigen Um Entwickler an verschiedenen Rechnern und Orten zu be teiligen muss das System ber ein Netzwerk verf gbar sein Der nat rliche Aufbau ei
87. than the other way around Oft wird der Algorithmus Code eines Programms als wesentlich angesehen und die Daten strukturen als blo es Hilfsmittel dazu Um ein Programm schnell zu verstehen sind saubere und dem Problem gut angepasste Datenstruktutren wesentlich die Algorith men ergeben sich dann meist fast von selbst In objektorientierten Programmierspra chen werden die Datenstrukturen als Klassen programmiert und unterst tzen damit diese Sichtweise 5 Often the most striking and innovative solutions come from realizing that your concept of the problem was wrong 4 3 Modularit t und Schnittstellen Computerprogramme sind eher f r Menschen geschrieben als f r Computer Aha Computerpro gramme sind doch ganz offensichtlich erstellt um auf Computern ausgef hrt zu werden Wenn das so w re w rde man heute nur noch Assemblerprogramme schreiben Abb 4 1 Oder direkt Maschinencode Stattdessen schreibt man Programme insbesondere solche mit 31 0200 Code starts at Address 0200 Main cla cll Clear AC and Link dca Q Zero Quotient dca R Zero Remainder tad B Load B sna skip if B not zero jmp Error halt if zero divisor cia Negate it dca MB Store at B tad A Load A Loop tad MB Add B spa Skip on Positive Accumulator jmp Done otherwise Done isz Q Increment Quotient jmp Loop and go again Done tad B Restore Remainder dca R and Save Error hit Halt Halt on Error jmp Main Go Again
88. timistischen Team Modell aus Es heift deshalb optimistisch da es davon ausgeht dass Konflikte selten auftreten Voraussetzung dazu ist eine hinreichende Modularisierung sowohl der Software als auch der Aufgaben oder zeitlichen Verteilung des Teams 2 commit festlegen bergeben 36 Entwickler A CVS Server Entwickler B Workspace Repository Workspace Coffee java Coffee java checkout Coffee java checkout Coffee java Y Y editieren editieren testen testen Y Coffee java Coffee java 7 i j i l i i i i i i i i i i i i j i I i kompilieren kompilieren i i i i i i i i i i i f I i l f I i l i update T 1 1 1 1 1 i Coffee java 1 1 1 m 1 N 7 nachbearbeiten kompilieren testen nicht OK Y Coffee java update _E_ _ _ OK HA Coffee java T 1 1 1 1 i A i commit 1 1 1 1 1 1 Abbildung 5 3 Der Ablauf der kollaborativen Entwicklung mit CVS bei einem Konflikt 5 2 1 Versionierung In CVS kann ein Projekt in zwei Arten vorliegen n mlich ver nderbar in einem Branch wie im vorigen Abschnitt beschrieben oder unver nderlich als eine Version Eine CVS Resorce also eine Datei ein Verzeichnis oder ein Projekt werden versioniert um einen Schnapp schus
89. twurf mit UML 2 2 Berlin Heidelberg Springer Verlag 2006 http dx doi org 10 1007 3 540 30950 0 11 STALLMAN R Why Open Source Misses the Point of Free Soft ware In LUTTERBECK B Hrsg B RWOLFF M Hrsg GEHRING R A Hrsg Open Source Jahrbuch 2007 Zwischen freier Software und Gesellschaftsmodell Berlin Lehmanns Media LOB de 2007 S 1 7 http www opensourcejahrbuch de portal article_show article 0sjb2007 00 02 en stallman pdf WINTER M Methodische objektorientierte Softwareentwicklung Eine Integration klassischer und moderner Entwicklungskonzepte Heidelberg dpunkt verlag 2005 12 aaa 53 Web Links moz http wiki mozilla org ReleaseRoadmap Release Roadmap des Mozilla Projektes 3 3 2008 swebok http www swebok org SWEBOK Guide to the Software Engineering Body of Knowled ge 2004 Version Handbuch des Gesammelten Wissens zum Software Engineering der IEEE Computer Society 3 3 2008 SVN http sonbook red bean com Online Version von Ben Collins Sussman Brian W Fitz patrick C Michael Pilato Version Control with Subversion O Reilly 2007 3 3 2008 tigris http tigris org Tigris eine Open Source Community das sich der Entwicklung und Bereitstellung von Tools des kollaborativen Software Engineering widmet 3 3 2008 54 Index u ere Qualit t 48 Abnahmetest 50 agile Sr agile Systementwicklung Aktivi
90. uf den ersten Blick benutzerfreundlich aussehen aber wenn damit tausend Benutzer einzutragen sind dann wird das nichts 4 2 Programmierleits tze nach OpenSource In seinem einflussreichen und sehr lesenswerten Artikel 7 untersucht Eric S Raymond an hand des Beispiels von Linux und seiner eigenen OpenSource Entwicklung des Mail Clients fetchmail die Programmiergrunds tze die eine Entwicklung nach einem Basar Modell von einer traditionell organisierten Kathedral Bauweise von Software mit zentralisierter Planung und wenigen hochspezialisierten Programmierern unterscheidet und die wie im Falle von Linux f r den berraschenden Erfolg verantwortlich sind Er nennt u a die fol genden 1 Every good work of software starts by scratching a developer s personal itch Notwendigkeit ist die Mutter der Erfindung Schreibe nur Programme die deine Probleme l sen aber keine die dich nicht interessieren oder die du nicht brauchst 2 Plan to throw one away you will anyhow Um ein Programm richtig zu schreiben sei bereit es mindestens einmal wegzuwerfen Oft beginnt man erst w hrend oder nach der ersten Implementierung das Problem und seine L sung zu verstehen 3 When you lose interest in a program your last duty to it is to hand it off to a competent successor Entsprechend dem ersten Leitsatz sollte derjenige ein Projekt betreiben der das gr te Interesse daran hat 4 Smart data structures and dumb code works a lot better
91. ufteilung der Rollen und Rechte zu berwachen h lt die Transparenz w hrend der gesamten Entwicklung aufrecht und unterst tzt da bei Verbesserungspotentiale zu erkennen und zu nutzen Er steht dem Team zur Seite 15 ist aber weder Product Owner noch Teil des Teams Er versucht f r die ordnungsge m e Durchf hrung und Implementierung im Rahmen des Projektes zu sorgen Er hat die Pflicht darauf zu achten dass der Product Owner nicht in den adaptiven Selbstor ganisationsprozess des Teams eingreift Die Spielphasen sind 1 Die Projektgrobplanung Es werden die Vorgaben f r das Projekt definiert beispielswei se die Projektzusammensetzung die verwendeten Entwicklungswerkzeuge und Stan dards z B Programmierrichtlinien Ferner erstellt der Product Owner in dieser Phase das Product Backlog das die Anforderungen an das zu entwickelnde Produkt enth lt 2 Die Game Phase Sie besteht aus mehreren Sprints d h Iterationsschritten der Dauer von etwa 30 Tagen die als Ergebnis jeweils eine lauff hige Software haben und in denen das Team grunds tzlich frei entscheidet wie es arbeitet d h in denen der Pro duct Owner keinen Einfluss nehmen darf Vor jedem Sprint allerdings werden gemein sam mit dem Product Owner in dem Product Backlog die Produktanforderungen und Priorisierungen besprochen und modifiziert und zu Beginn eines jeden Sprints mit ihm in einem Sprint Planning Meeting das Sprintziel festgelegt Der Scrum Master be 3
92. werden gab dass von dieser Ecke des Raumes zu gro er L rm kam wurde der Automat entfernt Daraufhin stieg jedoch der Beratungsaufwand der beiden angestell ten Tutoren so dramatisch dass sie die Anfragen der Studenten nicht mehr bearbeiten konn ten Was war passiert Der L rm der Studenten an dem Getr nkeautomaten r hrte daher dass sie ber ihre Computerprobleme miteinander sprachen und sie durch diese Kommu nikation an Ort und Stelle l sen konnten Nur au ergew hnlich schwere Probleme wurden so an die Tutoren herangetragen Durch die Wegnahme des zwar unkonventionellen aber auf diese Weise hocheffizienten Beratungsservice des Getr nkeautomaten sank die geistige Produktivit t obwohl das Gegenteil beabsichtigt war 2 3 1 Agile Softwareentwicklung Das Ziel agiler Softwareentwicklung ist es den Softwareentwicklungsprozess flexibler und schlanker zu machen als nach den klassischen Vorgehensmodellen Es soll mehr auf die zu 22 erreichenden Ziele geachtet und auf technische und soziale Probleme bei der Softwareent wicklung eingegangen werden Die agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und b rokratisch angesehenen Softwareentwicklungsprozes sen wie dem Rational Unified Process Ein ganz neuartiges Prinzip der agilen Softwareentwicklung ist die Paarprogrammierung pair programming Hierbei wird der Quelltext von jeweils zwei Programmierern an einem Rechner erstellt Ein Programmierer der
93. wird P L T werden in SVN die Koor dinaten umgekehrt P T L SVN bildet die erfahrungsgem Realit t von Ver nderungen damit anschaulicher nach denn jede Ver nderung ben tigt Zeit und ihre Endpunkte sind das Vorher Revision vor nderung und das Nachher Revision nach der nderung SVN versioniert oder revisioniert also grunds tzlich das gesamte Projektarchiv und damit jeweils die gesamte Verzeichnisstruktur w hrend CVS auf der unabh ngigen Versionierung jedes einzelnen Inhalts beruht 5 3 1 Revisionen Das Versionsschema von Subversion bezieht sich nicht mehr auf einzelne Dateien sondern auf das ganze Projektarchiv mit jeder nderung bekommt es eine neue Revisionsnummer zugeordnet Eine Revision in Subversion ist ein Schnappschuss des Repositorys zu einem bestimmten Zeitpunkt Jede Revision kann mit einem Kommentar versehen werden Bug xy behoben Mit Hilfe der Revisionen kann man einfacher und im Gegensatz zu CVS konsistent eine exakte Version beschreiben z B Revision 2841 statt Version vom 23 M rz 2008 20 56 31 UTC Die Revisionsnummer einer Datei entspricht dabei der Revisionsnummer des Projektarchivs als sie das letzte Mal ge ndert wurde die Revisionsnummer eines Ver zeichnisses entspricht der h chsten Revisionsnummer der enthaltenen Dateien und Ver zeichnisse Die Abfolge der Revisionsnummern einer einzelnen Datei kann also durchaus l ckenhaft sein wenn die Datei nicht bei jedem C
94. ystematische und effiziente Erstel lung von Software um das Usability Engineering d h die Untersuchung der Gebrauchstaug lichkeit von Software Das Application Engineering hat also zum Ziel Methoden Modelle Prinzipien und Werkzeuge zu untersuchen aus denen sich ein nicht nur effizientes und effizient hergestelltes sondern auch ein ergonomisches und qualitativ hochwertiges Pro dukt namens Software ergibt Diese beiden Aspekte also effiziente Herstellung und ergo nomische Gebrauchstauglichkeit von Software lassen sich in der Praxis freilich nur schwer trennen sie stellen lediglich zwei verschiedene zeitlich und inhaltlich oft eng verwobene Perspektiven der Software Entwicklung dar Grundbegriff des Application Engineering und damit insbesondere des Software Engi neering f r Wirtschaftsinformatiker ist die Applikation blicherweise auch Anwendungs system oder einfach Anwendung genannt Das ist ein Softwareprodukt das in bestimmten Anwendungsbereichen eingesetzt wird und Arbeits oder Gesch ftsprozesse unterst tzt oder gar ausf hrt beispielsweise in der Lagerhaltung der Finanzverwaltung oder der Auf tragsabwicklung Ein Anwendungssystem kann eine Individualsoftware sein die f r einen spezielen Auftraggeber in einem bestimmten Anwendungsbereich erstellt wird Ma an zug beispielsweise eine Webseite f r eine Firma oder eine Standardsoftware die allge mein einen bestimmten Anwendungsbereich abdeckt und durch Konfiguartio

Software Engineering

Contents

Download Pdf Manuals

Related Search

Related Contents