Home

Software-Qualität - Universität Klagenfurt

Contents

1. Parameter Assoziationsbeziehung Fur jede Methode m der Klasse A Fur jeden Parameter p der Methode m ORD ORD u As A KM p Abb 5 Generischer Algorithmus fiir ORDs Pr zise ORDs haben mehrere Vorteile Da sie nur die tats chlich auftretenden Abh ngigkeiten enthalten werden beim Testen auch nur diese ber cksichtigt Durch unpr zise ORDs kommt es zu berfl ssigen bzw fehlenden Testaufwand Im allgemeinen besitzen pr zise ORDs bis zu 40 weniger Abh ngigkeiten wodurch weniger Zyklen entstehen und so weitere Probleme vermieden werden siehe Abschnitt 4 134 159 3 3 Extended ORDs Extended ORDs Ext ORDs sind eine Erweiterung der schon beschriebenen ORDs Dabei werden Aggregations und Assoziations Kanten mit Zusatzinformationen beschriftet die aussagen welches Statement eine Abh ngigkeit ausl st Zwischen zwei Klassen k nnen so mehrere Kanten entstehen In Abbildung 6 ist ein Beispiel f r einen Ext ORD angegeben wobei aus Platzgr nden kein Quelltext angegeben ist Die Zahlen hinter dem Doppelpunkt der Abh ngigkeit stehen f r die Zeilennummer in der diese ausgel st wurde Abb 6 Ext ORD Der in Abbildung 5 beschriebene Algorithmus kann mit Hilfe von 2 Regeln zur Konstruktion von Ext ORDs erweitert werden e Es exisitiert eine Kante Ag s wenn Statement s eine Aggregationsbeziehung ausl st e Es existiert eine Kante As s wenn Statement s eine Variablen Zugriffs Assoziation oder ein
2. 16 JavaNCSS http www kclee com clemens java javancss 17 Clark Mike JDepend http www clarkware com software JDepend html 18 Littlefair Tim Software Metrics Investigation http cccc sourceforge net 19 Apache Software Foundation Jakarta Project http jakarta apache org 20 Dumke Reiner Softwaremetrie http ivs cs uni magdeburg de dumke Metrie Smetrie html 21 Briand Emam Morasca Theoretical and Empirical Validation of Software Product Measures http www software metrics org documents isern 95 03 pdf 22 Kitchenham Pfleeger Fenton Towards a Framework for Software Measurement Validation IEEE Transactions on Software Engineering 21 1995 929 944 http www sei cmu edu str descriptions mitmpm html 66 159 Management of Requirements Traceability Problems J rgl Kerstin Mat Nr 0060260 kjoergl edu uni klu ac at Abstract Requirements Traceability ist fiir die Entwicklung von Software Systemen mit hoher Oualit t wesentlich Wahrend das Traceability dass zur Verfeinerung Entwicklung und zum Gebrauch von einer Anforde rung Post Traceability genannt wird wird das Tra cing einer Anforderung zur ck zu seinem Ursprung pre traceability genannt In dieser Arbeit wird das grundlegende Problem des Requirements Tracing RT analysiert besprochen verarbeitet und M glichkeiten der Verbesserung pr sentiert RT wird als Pr
3. Damit findet der inhaltliche Teil dieses Sammelbandes seinen Abschluss Da es sich hierbei um das erste Bakkalaureatsseminar in Informatik an der Universit t Klagenfurt handelte und die Veranstaltung damit einen gewissen Erprobungscharakter hatte der freilich durch die Mischung von Bakkalareatsstudierenden mit klassischen Seminaristinnen und Seminaristen nicht unerheblich beeinflusst wurde wird die Gesamtdarstellung der studentischen Arbeiten durch eine methodische Reflexion des Lehrveranstaltungsleiters erg nzt M ge diese in Zusammenschau mit der Qualit t der studentischen Arbeiten k nftigen Seminarleitungen als Anregung f r allf llige Verbesserungen in der Gestaltung von Bakkalaureatsseminaren dienen Klagenfurt 4 Juli 2004 Roland Mittermeir Lehrveranstaltungsleiter 3 4159 4 159 Seminar aus Angewandter Informatik Globalthema Software Qualit t Vorwort Bakkalaureatsarbeiten Produktqualit t Akzeptanztests Unterguggenberger Ingrid Die Formale Inspektion eine spezielle Review Technik Dittrich Ursula Oualit tssicherung bei agiler Softwareentwicklung Graschl Mario Software im Automobil Qualit tssicherung durch MISRA Gauster Brigitte Prozessqualit t Aufwandssch tzung am Beispiel COCOMO II Esberger Daniela Metriken zur statischen Analyse objektorientierten Source Codes Urbani Edmund Management of Requirements Traceability Problems J rgl Kerstin Spannungen zwischen Benutzer
4. 7 Java unterst tzt Polymorphismus f r Attribute und Methoden beides mithilfe der dynamischen Bindung Jedes Objekt hat einen deklarierten Typ und einen aktuellen Typ Der aktuelle Typ kann vom deklarierten Typ erben Ein polymorphes Attribut ist eine Objektreferenz die unterschiedliche Typen annehmen kann Eine polymorphe Methode kann Parameter unterschiedlichen Typs akzeptieren Dies ist m glich wenn sie einen Parameter vom Typ Object besitzt 6 berladen Werden f r Konstruktoren und Methoden dieselben Namen aber unterschiedliche Signaturen verwendet spricht man vom berladen 6 Spezifische Merkmale von Java STATIC Wird eine Konstante oder Variable als statisch deklariert existiert nur eine Auspr gung davon egal wie viele Instanzen einer Klasse erzeugt werden Die Auspr gung der Klassenvariablen wird bei der Initialisierung der Klasse erzeugt Im Gegensatz dazu stehen die Instanzvariablen non static Jedes Mal wenn eine neue Instanz der Klasse erzeugt wird wird eine damit in Beziehung stehende Auspr gung der Instanzvariablen erzeugt Eine statische Methode Klassenmethode wird ohne Referenz auf ein bestimmtes Objekt aufgerufen 8 THIS Das Schl sselwort this bezeichnet einen Wert der eine Referenz auf das aktuelle Objekt darstellt ber diese Referenz k nnen berschriebene Instanzmethoden oder Instanzvariablen aufgerufen werden Der deklarierte Typ von this ist die Klasse in d
5. wareentwicklung repr sentieren Diese Grunds tze lauten wie folgt e Individuen und Interaktion gegen ber von Prozessen und Werkzeugen e lauff hige Software gegen ber von umfassender Dokumentation e Zusammenarbeit mit dem Kunden gegen ber Vertragsverhandlungen e Reaktionen auf Ver nderungen gegen ber Befolgung eines Planes Das Manifest der agilen Softwareentwicklung spie gelt die zentralen Werte der agilen Bewegung 9 wieder Aus diesem Werten kann die Abkehr von dem prozessorientierten Vorgehen hin zu einem den Ent wickler und Programmcode in die Mitte stellenden Vorgehen erkannt werden Daher kann die agile Soft wareentwicklung als programmcodeorientierte Me thode gesehen werden Diese Verschreibung an ein Manifest l sst die agile Softwareentwicklung in den Schein einer Glaubensfrage r cken Dieser Ansatz zeichnet sich in mancher Literatur nicht un hnlich der Streitigkeiten zwischen Linux und Win dowsverfechtern ab Daher ist bei der agilen Software entwicklung meist davon die Rede dass es sich um keinen neuen Prozess sondern eher um eine Einstel lung handelt Deshalb ist hier zu erw hnen dass stets die n tige Objektivit t bei den postulierten Vor und Nachteilen zu beachten ist Durch die Anpassung bestehender Prozesse kann aus diesen ein agiler Prozess entstehen diese Anpas sung soll durch den situationsgerechten Einsatz von agilit tssteigernden Praktiken geschehen Zu Beachten ist dass nicht jeder
6. Insgesamt kann gesagt werden dass die Anwen dung von GQM zur Selektion der relevanten Metriken f r AT amp T ein Erfolg war 5 Conclusio Die Einf hrung eines erfolgreichen Messpro gramms in einer Organisation ist eine gro e Heraus forderung Die Gr nde daf r sind zahlreich verschie dene Sichtweisen Modelle Zwecke Attribute und ihre Abh ngigkeiten untereinander GQM ist eine leis tungsf hige Methode die eine Datensammlung unter st tzt die genau auf die Ziele einer Organisation aus gerichtet ist Diese Arbeit soll aufzeigen dass der Ein satz von GQM in einer Organisation sinnvoll ist Bei der Einf hrung eines GQM Programms darf jedoch nicht au er Acht gelassen werden dass Schwierigkei ten auf verschiedenen Ebenen entstehen Das Mana gement muss berzeugt werden dass ein solches Pro gramm Vorteile bringt und auch die Mitarbeiter m s sen sensibilisiert und motiviert werden Wir sind der Meinung dass GQM einen sehr sinn vollen Ansatz zur zielorientierten Softwaremessung darstellt Die Grundstruktur von GQM wie sie in die ser Arbeit dargelegt wurde beinhaltet jedoch sicher lich nicht alle Aspekte die sich ein Unternehmen von einer solchen Methode erhofft Toolunterst tzung und eine verfeinerte Methode zur Definierung der Questi ons sind nur Beispiele daf r siehe auch 2 6 Referenzen 1 Basili V R G Caldiera and H D Rombach Goal Question Metric Paradigm in Enciclopedia of Soft
7. The study of requirements engineering in global software development as challenging as important International Workshop on Global Software DevelopmentOrlando Florida May 21 2002 105 159 Die Goal Question Metric Methode Jakab Michael 9960117 mjakab aon at Abstract Mit Hilfe der GOM Goal Ouestion Metric Metho de wird danach getrachtet eine prozess bergreifende kontextspezifische Auswahl von geeigneten Metriken zu erreichen die zur Evaluierung und zur Erlangung von Feedback aus speziellen Prozessen herangezogen werden kann 3 Die daf r n tigen Kenntnisse werden in dieser Arbeit theoretisch und auch anhand eines praktischen Beispiels illustriert Im praktischen Bezug ist auch die Betrachtung der in den Phasen der GOM Methode anfallenden Kosten die in dieser Arbeit eben falls behandelt werden von gro em Interesse Um dieses Verfahren in gegenw rtig existierende qualit tssichernde Standards einordenbar zu machen wird der qualit tssteigernde Effekt von GOM bei An wendung auf bestimmte CMM Ebenen wie er von Pfleeger in 5 gesehen wird beschrieben 1 Einleitung Die Software Entwicklung ben tigt zur Gewinnung von Feedback bzw Evaluierung der Qualit t ihrer Ar beit der Kosten der Risiken und des Fortschrittes ei nen geeigneten Mechanismus 1 Dieser die Soft waremessung ist der Prozess durch welchen Werte oder Symbole Attributen oder Entit ten in der realen Welt zugeordnet
8. berpr fung der Richtigkeit Verification Nachdem alle M ngel behoben worden sind berpr ft der Moderator die Modifikationen und kann gegebenenfalls einen zweiten Inspektions zyklus die Re Inspektion initiieren San Ferra aa Ausf hr ber ber Perera Entinng gt ung ung kd arbeitung ha pr fung Prozess Moderator Anforderungen gador Software Design Gutachter 2 Code Protokollf hrer amp Inspektion Testf lle Lesetechniken ad hoc Abbildung 2 Das Zusammenspiel der einzelnen Elemente einer Inspektion 3 4 Fehlerarten Die w hrend einer Inspektion identifizierten Fehler werden grunds tzlich in zwei Klassen unterteilt in Major beziehungsweise Minor Defekte Als Major Defekte werden die Fehler bezeichnet die m glicherweise erheblich h here Kosten verursachen wenn sie zu einem sp teren Entwicklungszeitpunkt gefunden werden Im Gegensatz dazu bleibt der Aufwand zur Behebung eines Minor Defektes immer derselbe Es hat dementsprechend keine gr eren Auswirkungen auf den Zeit oder Kostenplan ob der Fehler sofort oder erst sp ter korrigiert wird Das bedeutet allerdings nicht dass der Defekt nicht behoben werden muss Allerdings ist es m glich dass sich ein Minor Defekt wenn er nicht rechtzeitig behoben wird im Laufe des 23 159 Softwareentwicklungsprozesses in einen Major Defekt verwandelt Die Inspektion konzentriert sich haupts chlich auf die Auffi
9. bis zu dieser keine weitere Pr senzveranstaltung Der Fragetermin h tte dabei wohl entfallen k nnen Ein inhaltlich nur bedingt ausgef llter Termin unmittelbar nach Begutachtung der Extended Abstracts ist jedoch sinnvoll Die Einreichung und der Begutachtungsprozess der Vollbeitr ge erfolgte rein elektronisch wie bei Extended Abstracts Die Varianz der Gutachten war weit geringer als in der ersten Gutachtensrunde bei durchschnittlich hoher Qualit t Die Qualit t der Einreichungen war hingegen sehr unterschiedlich Insbesondere von den Bakkalaureats arbeiten waren noch zu viele als zu problematisch zu beurteilen als dass sie als akzeptabel geschweige denn als sehr gut zu beurteilen gewesen w ren Es wurde daher allen eine Nachfrist einger umt die Arbeit bis 1 Juli zu berarbeiten Von dieser Option haben alle Bakka laureanten auch jene mit sehr guten Ausgangsarbeiten und zw lf Seminaristen Gebrauch gemacht Die Pr sentationsphase Programm im Anhang verlief sehr diszipliniert allerdings viel zu gedr ngt Dies hatte zur Folge dass im Gegensatz zu bisherigen Konferenz seminaren inhaltlich nur relativ wenig zu den einzelnen Vortr gen diskutiert wurde Der Zeitplan erlaubte kaum mehr als eine inhaltliche Frage und kurze Statements zur Vortragstechnik sodass dieses Defizit nicht zu Lasten der Studierenden ausgelegt werden kann 5 Erfahrungen In diesem Teil m chte ich Erfahrungen generellerer Art f
10. pretation des GQM Plans bevor die tats chliche Da tensammlung durchgef hrt wird Dies erm glicht es Schwachstellen in der Definition des GQM Plans fest zustellen und zu korrigieren Datensammlungsphase In dieser Phase werden die Daten f r die im GQM Plan definierten Metriken gesammelt und gespeichert Wie diese Datensammlung vollzogen wird wurde be reits in der vorhergehenden Phase durch den Messplan festgelegt Dabei werden folgende Aspekte abgedeckt e Wer sammelt die Daten f r eine bestimmte Metrik e Wann werden die Daten erhoben e Wie k nnen die Daten am effektivsten und ef fizientesten gesammelt werden Tools e Wohin werden Daten zugeordnet Interpretationsphase Nach Abschluss der Datensammlung werden die gesammelten Werte ber den GQM Plan den zugeh rigen Questions zugeordnet Hieraus kann evaluiert werden ob oder inwiefern die definierten Goals er reicht wurden Abschlie end sollte eine Kosten Nutzen Analyse ber das GQM Programm durchgef hrt wer den um festzustellen ob die Anwendung f r die Or ganisation von Nutzen war 2 3 GQM und CMM W hrend einige Organisationen mit klar definierten Prozessen arbeiten sind andere variabler und ndern diese signifikant mit den Personen die gerade an ei nem Projekt beteiligt sind Das CMM Modell bildet diesen Sachverhalt auf f nf Stufen maturity levels ab Auf der niedrigsten Stufe initial sind kaum Informa tionen dar ber vorhanden wi
11. standen in Bereichen des Milit rs der Nuklearindustrie und der Automobilindustrie Um diese Standards aufgrund der Anforderungen der Wirtschaft deren unterschiedlichen Branchen und Interessensgruppen zu vereinheitlichen setzte die ISO 1979 ein Technisches Komitee ein Der Titel dieses TC 176 war Ouality management and quality assu rance und ihr Ziel war es einen Standard zu entwickeln der QM Systeme international vereinheit licht vgl ISO094 S 2 1985 erschienen die ersten Entw rfe der ISO 9000 9001 9002 9003 und 9004 Diese Entw rfe wurden von den verschiedenen Mitgliedsl ndern der ISO be arbeitet und die endg ltige Fassung der Normfamilie wurde 1987 von der ISO verabschiedet Damit die L nder der Europ ischen Union konkurrenzf hig ge gen ber den USA und Japan blieben wurde kurz darauf durch das CEN eine englische Version als EN 9000 1987 ff herausgegeben Da alle Mitgliedsstaaten verpflichtet waren diese Normreihe anzuerkennen wurden andere Normen verdr ngt und es kam zu einer Weiterverbreitung des ISO 9000 Standards 1990 wurde die Normfamilie DIN EN ISO 9000 bzw NORM EN ISO 9000 von Deutschland bzw sterreich ohne nderungen bernommen Obwohl die Normserie von der Wirtschaft begr t wurde und die Bedeutung durch das Einsetzen in be kannten Unternehmen stieg wurde auch Kritik ber 97 159 die Benutzerfreundlichkeit dieser Normen laut Zum Beispiel hatten Softwareunternehmen und Anbiete
12. 8 5 3 3 Inspacton Mean vUCL Abbildung 7 Beispiel einer Ausgabegraphik Leider ist dieses Tool schon etwas veraltert und bietet dem Benutzer im Bereich der Arbeits oberfl che keinen besonderen Komfort Au erdem funktioniert LIDS nur mit Lotus 1 2 3 Release 5 01 oder lteren Versionen Laut Auskunft von Robert Ebenau dem Autor von LIDS ist nicht geplant LIDS f r neuere Versionen lauff hig zu machen Da Lotus 1 2 3 Release 5 01 jetzt nicht mehr im Handel verf gbar ist muss es anderweitig beschafft werden Die Idee einer Toolunterst tzung zur Verwaltung der Inspektionsdaten ist zwar grunds tzlich gut und n tzlich entspricht aber in der Version die mir zur Verf gung stand in keinster Weise mehr dem heutigen Softwarestandard 5 Zusammenfassung amp Schlussfolgerung Um qualitativ hochwertige Softwareprodukte herstellen zu k nnen sind zahlreiche berpr fungen der Produkte und Zwischenprodukte notwendig Diese berpr fungen m ssen in jeder Phase der Softwareentwicklung umgesetzt werden Reviews und Inspektionen sind gut geeignet um diese berpr fungen bereits in fr hen Phasen der Softwareentwicklung f r alle Arten von Softwareprodukten beispielsweise Anforderungs 97 459 dokumente durchzuf hren Die Hauptgr nde daf r warum gerade in der fr hen Entwicklung also in der Anforderungsanalyse Planung und Spezifikation Fehler vermieden werden sollten liegen darin dass diese Fehler vie
13. Entwicklung Test Sicherung Sybex Verlag GmbH D sseldorf 1990 3 Manfred R tzmann Software Testing Galileo Press GmbH Bonn 2003 4 Dorothy Graham Requirements and Testing Seven Missing Link Myths IEEE Software September October 2002 pp 15 17 5 Homepage des Ministeriums fiir Sustainable Resource Management des Governments of British Columbia URL http srmwww tov be ca 6 Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus und Weiterbildung zum Certified Tester dpunkt Verlag Heidelberg 2003 7 Martin Pol Tim Koomen and Andreas Spillner Mana gement und Optimierung des Testprozesses ein praktischer Leitfaden fiir erfolgreiches Testen von Software mit TPI und TMap 2 aktualisierte Auflage dpunkt verlag GmbH Hei delberg 2002 8 Norman Parrington Marc Roper Software Test Ziele Anwendungen Methoden McGraw Hill Book Company GmbH Hamburg 1990 9 Edward Kit Software Testing in the real world by the ACM Press a division of the Association for Computing Machinery Inc ACM 1995 10 Raymond Kehoe Alka Jarvis ISO 9000 3 A Tool for Software Product and Process Improvement Springer Ver lag New York 1996 11 William Perry Effective methods for Software Testing John Wiley amp Sons Inc Canada 1995 12 Das Wiki Wiki Web Internetforum URL http c2 com cgi wiki AcceptanceTest 13 Ernest Wallm ller Software Qualit tsmanagement in der Pra
14. Marchesi M Succi G Wells D Williams L Extreme Programming Perspectives Addison Wesley Boston 2002 23 Jalote P An Integrated Approach to Software Engineering 2 ed Springer 1997 p 11 38 159 Software im Automobil Qualit tssicherung durch MISRA Gauster Brigitte 0060077 bgauster edu uni klu ac at Abstract In dieser Arbeit wird Ihnen anfangs ein Einblick ber die Verwendung von Software in den Kraftfahrzeugen gegeben und welche Auswirkungen ein Versagen dieser Systeme haben kann Durch die angef hrten Fehlfunktionen soll die Bedeutsamkeit der Oualit t der eingebauten Software hervorgehoben und des Weiteren spezielle Verfahren und Metriken zur Sicherung dieser vorgestellt werden Das Hauptaugenmerk richtet sich hierbei auf MISRA The Motor Industry Software Reliability Association die besondere Richtlinien f r den Automobilsektor entwickelt hat um eine Hilfestellung bei der Entwicklung von life critical Software zu geben Abschlie end wird Ihnen noch ein kleiner Blick in die Zukunft gew hrt und einige neu anrollende Techniken vorgestellt 1 Einleitung Das Automobil ist weltweit zu einem Symbol f r Fortschritt und Entwicklung geworden und zugleich ein Statussymbol f r die meisten B rger Undenkbar erscheint es f r uns kein Fahrzeug zu besitzen um damit von einem Punkt zum anderen zu gelangen Doch heute ist der PKW nicht nur mehr ein Fahrzeug Ausgestattet mit neuen mechan
15. Norm zu entsprechen k nnen gegebenenfalls fr hzei tig Verfahren entworfen werden Diese werden wie derum koordiniert und letztendlich wiederum getestet 67 159 Denn nur so kann gew hrleistet werden dass alle er forderlichen Funktionen Anforderungen und Design komponenten im Produkt vorhanden sind 2 1 2 Kostenreduktion Traceability l sst alle Produktanforderungen sehr fr h im Life Cycle der Entwicklung zuteilen und somit erheblich Geld sparen Die Kosten die sonst beim Warten entstehen bis Integration und System Test Phase abgeschlossen ist um Defekte zu beheben ist ein fixer Bestandteil und 30 mal st rker als bei der vorgesehenen Ausgangsphase 2 1 3 Verantwortlichkeit W hrend der internen oder externen Bilanzen hat das Projekt eine bessere Erfolgsrate wenn die Daten f r Revisoren vorhanden sind und sie pr fen k nnen ob eine Anforderung erfolgreich durch verbundene Testf lle validiert wurde Projektmanager haben einen besseren Handgriff bez Kosten und dem Kunden wird beim Erhalt des Produktes versichert dass er bekommt was er verlangt hat Indem man quantitative Analysen zur Verf gung stellt k nnen Projektmeilensteine leicht genehmigt und so leichter berpr ft werden was wie derum die Kundenzufriedenheit erh ht und das Ver trauen steigert 2 1 4 Change Management F r jede nderung ist es einfacher festzustellen in welcher Verbindung die Elemente zum Design stehen und wie diese dad
16. Sp tere Entdeckungen k nnen 2 bis 10 Mal teurer sein O Neil 1995 3 8 Vor und Nachteile der Inspektion Software Inspektionen sind ein wichtiges Instrument um hohe Qualit t im Prozess der Softwareentwicklung zu erreichen Je fr her Fehler entdeckt werden desto geringer ist der Kosten und Zeitaufwand der erbracht werden muss um sie zu beheben Wo diese Kosteneinsparungen in einem Softwareprojekt m glich sind zeigt Abbildung 4 mit den verschiedenen Phasen eines Softwareprojekts In jeder dieser Phasen gibt es einen Anteil an T tigkeiten der nur deshalb n tig ist weil Menschen nicht von vornherein absolut fehlerfrei arbeiten k nnen in der Abbildung mit Rework bezeichnet Wenn zum Beispiel im Integrationstest ein Fehler gefunden wird kann es sein dass sich dieser Fehler als Designfehler herausstellt Dann muss ein Designdokument ge ndert werden einige Funktionen m ssen neu programmiert werden Modultests m ssen nachgeholt werden und dann erst kann der Integrationstest wieder aufgenommen werden Dieser ganze Aufwand w re nicht n tig gewesen wenn der Fehler bei einer Inspektion des Designdokuments gefunden worden w re Durch den regelm igen Einsatz von Inspektionen k nnen circa 2 3 des Rework Anteils eines Softwareprojektes so durch Inspektionen wegoptimiert werden Rework 44 EI Production 56 Requirements Preliminary Detailed Code amp Unit Integration amp Design Design Test System Test Abb
17. Tests wird von den Entwicklern oder Testern durch gef hrt um die Anforderungen hinsichtlich der Leis tung zu berpr fen und zu bewerten Hinsichtlich der Qualit tssicherung sollen die Performance Tests das Kriterium der Effizienz berwachen 6 5 Die Rolle des Testers Im Gegensatz zum traditionellen Ansatz wo die Rolle des Testers anhand der Prozessstruktur klar de finiert ist scheint sie bei Verwendung von agilen Methoden sehr beschnitten beziehungsweise kaum vorhanden Da die Spezifizierung und Durchf hrung von Tests vermehrt vom Kunden und dem Entwickler durchgef hrt wird stellt sich die Frage Haben Tester in der agilen Softwareentwicklung noch Platz Der Tester im herk mmlichen Sinn das hei t Mo dellierung der Testf lle anhand der Anforderung an das Produkt erstellen eines Testberichtes erneutes Testen usw scheint berfl ssig geworden zu sein Die Rolle des Testers in einem agilen Softwareentwick lungsprozess ist vielmehr eine zwiesp ltige n mlich die eines Kunden und Entwicklers Der Tester ist durch die Art des Prozesses in die Entwicklung invol viert ist aber zugleich dazu angehalten die Sicht des Kunden nicht zu verlieren Zu diesem Zweck ist der Tester meist bei der Erstellung der Akzeptanztest dem Kunden beigestellt dies geschieht in erster Linie um den Kunden bei der Bedienung von Testtools und bei der Formulierung der Testf lle behilflich zu sein Im weiteren Verlauf ist der Tester f r die Auswe
18. Zur Laufzeit k nnen aber durch Polymorphismus Abh ngigkeiten entstehen die in diesem ORD nicht aufscheinen Ein weiteres Problem sind im ORD verzeichnete Abh ngigkeiten die zur Laufzeit nicht entstehen Von Labiche et al wurde ein verbesserter ORD vorgestellt bei dem auch die dynamischen Abh ngigkeiten ber cksichtigt werden 7 Allerdings wurde dabei das Problem berfl ssiger Abh ngigkeiten sogar noch verst rkt Milanova et al pr sentierten eine M glichkeit pr zise ORDs zu konstruieren 1 Abb 3 ORD nach Milanova et al Die Abbildungen 2 und 3 stellen die eben beschriebenen ORD Varianten die aus dem Java Code von Abbildung 4 resultieren dar Kungs ORD ber cksichtigt nur die statischen Abh ngigkeiten 133 159 zwischen den 3 Klassen die direkt aus dem Quelltext abgelesbar sind Die Assoziationsbeziehung entsteht dabei weil in der Klasse Assoc eine Methode eines im Konstruktor bergebenen Parent Objekts aufgerufen wird Labiche hat eine einfache Regel eingef hrt wonach jede Subklasse die Assoziationsbeziehungen seiner Superklasse erbt Dies geht aus Abbildung 2 hervor Die von Milanova et al vorgestellten ORDs enthalten nur jene Abh ngigkeiten die zur Laufzeit tats chlich auftreten siehe Abbildung 3 3 1 Klassenabh ngigkeiten Zun chst wollen wir Klassenabh ngigkeiten die aus Java Quellcode gewonnen werden k nnen beschreiben 1 Dabei wird die Notation KA A B zur Beschreibung der Abh ng
19. chen Vorlesungen und Designanmerkungen das Time Recording Logbuch siehe 5 1 2 sowie Ver 124 159 weise auf Pr fungen und Vereinbarungen enthalten Im Falle einer Klage kann es dem Unternehmen auch als Beweismittel dienen Beispiel Ein Engineering Notebook Eintrag der die Haupt Kategorie Hausaufgaben dokumentiert Date 3 9 9 CSI assignment due 9 16 Make an engineering notebook Reference page 206 textbook Read programming text chapter 1 9 11 CSI assignment due 9 20 Do programming exercises chapter 1 9 13 CSI assignment due 9 23 Read programming text chapter 2 Review the exercises in chapter 2 and prepare for quiz Abb 5 1 Engineering Notebook 5 1 2 Time Recording Logbuch Das Time Recor ding Logbuch bietet die M glichkeit R ckschl sse auf seine Arbeitsweise zu ziehen indem man die Zeit die man f r einzelne T tigkeiten w hrend eines Projektes ben tigt misst Ist man in mehrere Projekte gleichzeitig involviert wird f r jedes einzelne ein eigenes Logbuch angelegt Dasselbe k nnte man auch im Projektunterricht an der Schule durchf hren Die Zeitmessung erfolgt in Minuten Neben der Zeitnahme f r die eigentlichen Aufgaben wie etwa programmieren ist es ebenfalls unbedingt n tig die Dauer banaler Unterbrechungen wie Kaffeepausen oder E Mail Bearbeitung w hrend einer Aktivit t auf zuzeichnen Es ist ebenfalls wichtig
20. keine Schulung f r die Benutzer sprich also f r den Fahrer gibt Des Weiteren werden in den Richtlinien Basis Prinzipien festgelegt die f r die Softwareentwicklung unumg nglich sind Sicherheit muss vorhanden sein Je gr er das Risiko desto gr er mu die Menge an Information sein e SW Robustheit Verl sslichkeit und Sicherheit m ssen genauso wie die Qualit t w hrend der Entwicklung entstehen nicht im nachhinein e Sicherheit ist wichtiger als Kundenw nsche Systemdesign mu Fehler auffangen k nnen Sicherheit muss w hrend dem Design Entwurf und der Herstellung miteinbezogen werden e Je sp ter nderungen vorgenommen werden desto gr er sind die daraus resultierenden Risiken Diese Voraussetzungen bilden den Grundstock f r die weitere Entwicklung die von MISRA als Software lifecycle bezeichnet wird und mit einem SW Entwicklungs Plan seinen Anfang nimmt Dieser beinhaltet Spezifikation Design Programmierung Integration der SW in die vorhandene HW sowie Verifikation und Validation Darauf folgt der Qualit tsplan gefolgt vom Sicherheitsplan der die Aufgabe hat die Verifikation und Validation w hrend des Projektes zu unterst tzen Den Abschluss bildet der Konfigurations Management Plan der so wie die anderen genannten Pl ne vor Anlauf des Projektes erstellt werden muss So wurde bereits erw hnt dass ein Sicherheitsplan vor Beginn des Projektes von gro er Bedeutung ist Die dazugeh rige
21. liegen wo die Grenze zwischen Freiheit und Lenkung k nftig gezogen wird Zu hoffen bleibt dass nicht quantitative Restriktionen dazu f hren dass von der gesetzlichen M glichkeit der Engf hrung zu restriktiv Gebrauch gemacht werden muss mation durch das werden kann 150 159 Begutachtungsverfahrens gen tzt Anhang 1 Seminar aus Angewandter Informatik Seminar aus Betriebsinformatik Beginn R Mittermeir Di 2 M rz 2004 8 15 Sommersemester 2004 Seminarraum 2 42 Seminarordnung Das Seminar wendet sich an vier Zielgruppen mit durchaus unterschiedlichen Vorkenntnissen und auch unterschiedlichen Zielvorstellungen Prim r wollte es die Studienkommission als dreist ndige Lehrveranstaltungen f r Bakkalaureats Studierende aus Informatik konzipiert wissen Dar ber hinaus ergab sich der Bedarf es als zweist ndige Lehrveranstaltung f r Lehramtsstudierende Betriebswirtschafts Studierende und ggf auch f r Diplomstudierende aus Informatik die noch im zehnsemestrigen Diplomstudium sind und nicht die Ausweich Variante eines zus tzlichen Seminars aus dem gebundenen Wahlfach annehmen wollen bzw k nnen zu gestalten Der Unterschied im Stundenausma ist dabei insofern das geringere Problem als aufgrund des Bakkalaureats Studienplans die Aufstockung des Stundenausma es um eine Stunde mit der Notwendigkeit der Abfassung einer ber die Anforderungen an eine Seminararbeit hinaus gehenden Bakkalaureatsarbeit begr nde
22. 0 707 Martins Metriken m gen zwar einige gute Ans tze enthalten und durchwegs schl ssig erscheinen aber trotzdem sind sie mit Vorsicht zu genie en Tats chlich konnte die OO Design Quality Metrik bis dato nicht validiert werden Mehr zum Thema der Validierung kommt sp ter in Kapitel 5 1 4 Tools f r Java Alle bisher beschriebenen Metriken sind unabh ngig von konkreten Programmiersprachen definiert Wie einige der Metriken f r die Programmiersprache Java umgesetzt wurden wird in diesem Kapitel anhand von Open Source Tools gezeigt 4 1 JMetric 15 JMetric ist das Ergebnis von Forschungen der School of Information Technology an der Swinburne University of Technology Das Programm ist frei verfiigbar unter den Bedingungen der GPL In JMetric sind einige traditionelle Metriken implementiert Statements und Lines of Code sowie Cyclomatic Complexity Letztere wird nur auf einzelne Methoden angewandt Weighted Method Complexity oder Average Method Complexity werden nicht berechnet Als einzige OO Metriken stehen drei verschiedene Varianten von LCOM zur Auswahl unter anderem die urspr ngliche Variante von Chidamber und Kemerer Das Projekt scheint zum letzten Mal im Jahr 2000 eine neue Version ver ffentlicht zu haben Der praktische Nutzen dieses Werkzeugs ist leider nicht besonders gro vor allem weil die Dokumentation eher sp rlich und die Bedienung recht m hsam ist und au erdem auch mit keiner Weiterentwickl
23. 04 sp ter Nachmittag Abend Feedback f r 2h Arbeiten Mai 04 offen wird am 11 Mai besprochen Fallfrist Mai 04 Vortr ge 2h Arbeiten 1 Runde Vortragsdauer 15 max 20 min weiteres Programm soweit bis dahin nicht bereits festgelegt wird am 25 Mai besprochen Bakkalaureats Vortr ge beginnen ab 8 Juni 04 25 bis max 30 min 153 159 Anhang 2 Seminar aus Angewandter Informatik Seminar aus Betriebsinformatik Beginn R Mittermeir Di 2 M rz 2004 8 15 Sommersemester 2004 Seminarraum 2 42 Software Qualit t Call for Contributions Aufruf zur Beitragseinreichung F r das Seminar aus Angewandter Informatik Betriebsinformatik werden Beitr ge aus dem Bereich Software Qualit t erbeten Bedenken Sie dabei dass Software Qualit t aus unterschiedlichen Aspekten beleuchtet werden kann Entsprechend der sehr unterschiedlichen Teilnehmer Population am Seminar erwarte ich Beitr ge zu e anwendungsbezogenen Themen wie etwa o Qualit t im Sinne von Usability o Qualit t im Sinne von Integrierbarkeit in die betriebliche Umwelt o Qualit t im Sinne von Prozessverbesserung innerbetrieblicher Abl ufe durch Software Qualit t und Software Release Politik e prozessbezogenen Themen wie etwa o Qualit t des Software Entwicklungsprozesses o Zertifizierung des Software Entwicklungsprozesses CMM ISO SPICE o Qualit t einzelner Phasen des Prozesses o Life Cycle bergreifendes Qualit tsmanage
24. 5 S Chidamber Ch Kemerer A Metrics Suite for Object Oriented Design IEEE Transactions on Software Engineering Volume 20 No 6 June 1994 pp 476 493 6 R Dumke E Foltin Metrics based Evaluation of Object Oriented Software Development Methods Preprint Nr 10 Fakultat fiir Informatik Universitat Magdeburg 1997 URL http ivs cs uni magdeburg de sw eng agruppe forschung paper ooeval pdf 7 Ch Ebert R Dumke Software Metriken in der Praxis Einf hrung und Anwendung von Software Metriken in der industriellen Praxis Springer Verlag 1996 8 K El Emam S Benlarbi N Goel S Rai A Validation of Object oriented Metrics NRC ERB 1063 NRC Publication Number NRC 43607 October 1999 URL http t iti nrc cnre ge ca publications nrc 43607 e html 9 K El Emam A Methodology for Validating Software Product Metrics NRC ERB 1076 NRC Publication Number NRC 44142 June 2000 URL http iit iti nrc cnrc gc ca iit publications iti docs NRC 44142 pdf 10 K El Emam S Benlarbi N Goel S Rai The Confounding Effect of Class Size on the Validity of Object Oriented Metrics IEEE Transactions on Software Engineering Volume 27 No 7 pp 630 650 July 2001 11 K El Emam Object Oriented Metrics A Review of Theory and Practice Advances in software engineering Springer Verlag New York Inc New York NY 2002 12 K Erni Anwendung multipler Metriken bei der Entwicklung objektorientierter Framework
25. 95 1 07 1 15 1 24 PDIF 0 87 1 29 1 81 2 61 PERS 212 1 62 1 26 0 83 0 63 0 50 PREX 1 59 1 33 1 22 0 87 0 74 0 62 FCIL 1 43 1 30 1 10 0 87 0 73 0 62 SCED 1 43 1 14 1 1 n a Faktor Bemerkungen Neuartigkeit Erfahrung mit dieser Art von Pro jekten 0 totale Vertrautheit 5 keine Erfahrung Entwicklungs Flexibilit t im Entwicklungsprozess flexibilit t 0 keine Vorgaben der Prozesse 5 Vorgabe des zu verwendenden Prozess Architektur Umfang der Risikoanalyse Risikoaufl 0 vollst ndige Analyse sung 5 geringe keine Analyse Teamzusam Vertrautheit und Zusammenarbeit menhalt im Team 0 integriertes und effektives Team 5 sehr schwierige Interaktion Ausgereiftheit Ausgereiftheitsgrad des Prozesses des Prozesses abh ngig vom CMM Maturity Questionnaire Sch tzung durch Abzug des Ausgereiftheitsgrades des CMM Prozesses vom Wert 5 Der Multiplikator M in der Formel des Early De sign Models siehe Abbildung 4 gibt eine vereinfachte Reihe von Projekt und Prozessfaktoren wieder Dazu z hlen RCPX Product Reliability and Complexity die Produktzuverl ssigkeit und komplexitat RUSE Developed for Reusability der ben tigte Wiederverwendungsgrad PDIF Platform Difficulty der Schwierigkeitsgrad der Plattform PERS Personnel Capability die Mitarbeiterfahigkeiten Alternativ zu
26. Auftraggeber bergeht da mit Bestehen des Abnahme tests die Entwicklungsphase abgeschlossen ist und die Wartungsphase beginnt Deshalb ist es wichtig dass der Abnahmetest korrekt durchgef hrt wird Dies ist allerdings nur dann m glich wenn die entsprechenden Abnahmekriterien gut gew hlt sind Genau diese Problematik wird in dieser Arbeit an hand von Richtlinien laut ISO 9000 3 bez glich Benut zerakzeptanz und einiger Webseiten die Dienstleistun gen zu diesem Thema anbieten oder sonstiges Wis senswertes dazu zu bieten haben er rtert Au erdem werde ich versuchen den Zusammenhang zwischen einem gut durchgef hrten Abnahmetest und der Quali t t des gesamten Softwareproduktes n her zu beleuch ten Der Leser soll mit Hilfe dieser Arbeit die Wichtig keit des Abnahmetests erkennen und Grundlagen f r die Ausf hrung und Einsch tzung eines solchen erlan gen 1 Was ist ein Akzeptanztest Ein Akzeptanztest ist Ein Test ausgef hrt f r ein Software oder Hardwaresystem um dessen funktio nale Leistungsf higkeit bez glich vordefinier ter festgelegter Erfordernisse zu evaluieren Testet und bewertet Leistung Funktion Effizienz Performance und Konformit t gegen ber den bestimmten Aufgaben eines neu angeschafften Systems 1 In anderen Worten ausgedr ckt Ein Abnahmetest ist ein Test der am Ende der Entwicklungsphase eines Systems meistens vom Benutzer selbst durchgef hrt wird und pr fen soll ob das entwi
27. DM design modifications f r den prozentuellen Anteil des ge n derten Entwurfs CM code modifications f r den pro zentuellen Anteil des ge nderten Codes und IM modi fications for integration f r den prozentuellen Anteil des anf nglich erforderten Aufwandes f r die Integra tion der wiederverwendeten Software SU source usa bility ist ein Faktor der auf den Kosten f r das Be herrschen der Software basiert Der Wert kann variabel zwischen 10 und 50 gew hlt werden 10 bedeutet dass der Code gut geschrieben und objektorientiert ist Bei 50 handelt es sich um einen sehr komplexen und un strukturierten Code Der Faktor AA application as sessment spiegelt die urspr nglichen Beurteilungskos ten f r die Entscheidung ber die Wiederverwendung der Software wider Auch hier kann der Wert variabel gew hlt werden Der Wertebereich liegt zwischen 0 und 8 Wie beim Early Design Model wird ebenso hier fiir A der Erfahrungswert 2 5 eingesetzt Auch der Expo nent E kalkuliert sich wie bereits im vorigen Modell demonstriert und an der Berechnung von PM andert sich genauso wenig 2 4 Einsatzgebiete COCOMO II wurde entwickelt um bei folgenden Entscheidungen und Situation zu helfen BOEH00 Entscheidungen die die Investitionen eines Soft wareprojektes betreffen Festsetzungen von Projektbudgets und Zeitpl nen Wie viele Mitarbeiter werden in welcher Phase gebraucht Wie hoch ist der Aufwand zur Errei chung eines
28. Diese Herausforderungen bedingen dass die Arbeit eines Requirements Engineers in globalen Projekten anspruchsvoller ist als bei lokalen Projekten Der Requirements Engineer muss ein gr eres Ma an Koordinationsf higkeit mitbringen und auch die F higkeit die wichtigen Fragen im Fokus zu behalten Dinge die sonst vielleicht ber informelle Kommunikation kolportiert werden m ssen explizit angesprochen und gekl rt werden 2 2 Wissensmanagement Wie im vorigen Abschnitt besprochen ist Kommunikation ein wichtiges Thema w hrend der Requirements Engineering Phase Das liegt daran dass das Wissen der einzelnen Stakeholder gesammelt und koordiniert werden muss Gro e Teile des ben tigten Wissens sind nirgendwo dokumentiert sondern befinden sich laut Zowghi 2 nur in den K pfen der jeweiligen Personen Erst die gesammelte Menge an Information macht es schlussendlich m glich eine Definition der ben tigten Anforderungen zu erstellen die den Projektzielen tats chlich entspricht Dieses undokumentierte Wissen wird teilweise auf informelle Weise zwischen den verschiedenen Teilnehmern ausgetauscht In einem globalen Projekt m ssen die Informationen formaler verwaltet werden Es ist daf r zu sorgen dass das Wissen einzelner dokumentiert und allen anderen zu Verf gung gestellt wird 2 3 Zeitverschiebung Ein weiterer Einflussfaktor ist die Zeitverschiebung Synchrone Kommunikation kann nur stattfinden wenn beide Teams anwesend
29. Eine Test Suite ist eine Menge solcher Test F lle 6 Unit Test Integrations Test System Test Beim Unit Test wird die Korrektheit der individuellen Kom ponenten getestet F r den Integrations Test werden mehrere Komponenten zu einem Subsystem zusam mengebaut und als Einheit getestet Beim System Test wird wiederum aus mehreren Subsystemen das System zusammengestellt und als Gesamteinheit getestet 4 berdeckungsgrad Regressionstest Der berde ckungsgrad ist ein Ma f r den Grad der Vollst ndig keit eines Tests bezogen auf ein bestimmtes Testver fahren Beim Regressionstest handelt es sich um die Wiederholung der bereits durchgef hrten Tests nach einer nderung im Programm 6 White Box Test Black Box Test Beim White Box Test werden die Testf llen aus dem Sourcecode er zeugt Die innere Struktur des Programms muss daher bekannt sein Black Box Testen ist ein dynamisches Testverfahren bei dem die Testf lle aus der Pro grammspezifikation abgeleitet werden Die Programm struktur wird dabei nicht beachtet 6 4 Modelle Ans tze des Testens komponen tenbasierter Software Ein Reihe m glicher Modelle bzw Ans tze des Testens komponentenbasierter Software wird in die sem Abschnitt vorgestellt Es handelt sich dabei nicht um Alternativen sondern um m gliche L sungen eini ger der vorher beschriebenen Probleme die an ver schiedenen Stellen ansetzen 4 1 Repository Design Weyuker 4 schl gt eine
30. Gruppierungen aus Der Gro teil wird hier der Endbenutzer programmierung zugeordnet Hier handelt es sich in der Regel um kleine Projekte wo der Programmierer in vordefinierten Umgebungen zB Tabellenkalkulati on SQL Client Planungssysteme arbeitet und das Programm auf die Bed rfnisse des Endbenutzers ab stimmt Hier wird aufgrund des geringen Projektum fangs nur eine sehr einfache Aufwandssch tzung ben tigt Endbenutzerprogrammierung 55 Millionen Programmierer in den USA 2005 Generierung v pp an UD Systemintegration u Hilfsmittel plikationen 0 7 0 7 Millionen f r d Aufbau Millionen 0 6 Millionen Infrastruktur 0 75 Millionen Abbildung 1 Bereiche der SW Entwicklung BOEH00 Die mittlere Ebene umfasst folgende drei Unter gruppen l Generierung von Applikationen und Hilfsmittel f r den Aufbau Es erfolgt h ufig eine Wiederverwendung von Komponenten aber auch neue Funktionalit ten werden hinzugef gt Die bekanntesten Firmen in diesem Sektor sind beispielsweise Microsoft Net scape Lotus Novell und Borland 2 Aufbau von Applikationen Hier kann keine Wiederverwendung der Kompo nenten aufgrund von Umfang oder Diversifizie rung der Produkte erfolgen Allerdings k nnen die Komponenten zB graphische Benutzer schnittstellen leicht mittels CASE Werkzeugen erstellt werden 3 Systemintegration Man spricht hier von systemnaher embedded Software die vor all
31. Helmy System Analysis and Design Pitman Publishing London 1994 7 Deborah J Mayhew Principles and Guidelines in Software User Interface Design Prentice Hall Verlag New Jersey 1992 8 A Russel Jones Linux vs Windows Choice vs Usability http www devx com opensource Article 16969 9 Ashley George Taylor WIMP Interfaces CS6751 Topic Report Winter 97 http www cc gatech edu classes cs675 1_97_winter T opics dialog wimp 10 ETHICS Backgrounds and ETHICS overview http www macs hw ac uk ism ug2 AssS5 ethics html 11 Christian Dahme http waste informatik hu berlin de Dahme edidahm pdf 1997 Wolfgang Hesse 12 Carma McClure The three Rs of Software Automation Reengineering Repository Reusability New Jersey 1992 13 Enid Mumford Effective systems design and analysis requirements Macmillan Verlag New York 1995 14 James A Kowal Behavior Models specifying user expectations Prentice Hall Publishing New Jersey 1992 85 159 86 159 Seminararbeiten 87 159 88 159 CMM Eine Einf hrung Gudrun Egger 9711612 gegger edu uni klu ac at Abstract Die Anspr che an die Softwareentwicklung wachsen st ndig Diesen Anspr chen ist der Projektalltag oft nicht gewachsen Die Gef hrdung von Projekten ist aktueller denn je Software organisationen die ihr Risiko erfolgreich managen k nnen
32. Kreise gemeinschaftlich durchgef hrte Vereinheitlichung von materiellen und immate riellen Gegenst nden zum Nutzen der Allgemeinheit Sch601 S 8 Die Aufgabe einer Norm ist ein einheitliches Ver st ndnis von Begriffen und Abl ufen zu schaffen um die Kommunikation zwischen zwei Partnern zu er leichtern Der Handel sollte dadurch effizienter sicherer und gerechter gestaltet werden Ebenso sollten die Normen f r die Kunden und Benutzer ein Hilfsmit tel f r die berwachung von Produkten und Dienstleistungen sein Genormte Produkte sollen defi nierte Eigenschaften aufweisen und mit einem nach der selben Norm gefertigten Produkt eines anderen Herstellers ausgetauscht werden k nnen 2 2 Normungsinstitute 2 2 1 ISO International Organization for Stan dardization Diese internationale Organisation wurde am 26 Oktober 1946 gegr ndet und ihr Hauptquartier liegt in Genf Im Mai 2004 betrug die Anzahl der beteiligten L nder 148 Die Aufgabe der ISO ist die Erarbeitung von internationalen Normen um die unterschiedlichen nationalen Normen anzugleichen und zu vereinheitli chen Sie sind eine Grundlage f r den freien Welthandel Die Erarbeitung der Normen wird in Technische Komitees Technical Committees kurz TCs genannt erledigt Im Mai 2004 existieren 225 solcher TCs Die Gesamtanzahl der von der ISO ver abschiedeten Normen seit ihrer Gr ndung betr gt ca 13 700 vgl www iso org 2 2 2 CEN Comit Europ en de
33. Mutanten f r Java Programme Daniel PEINTNER Der optimale Software Release Zeitpunkt Stefan LAMPICHLER Petra TESSARS Remote Usability Testing Marion KURY Requirements Engineering in globalen Projekten Programm der 2 Vortragsrunde 8 Juni 2004 SR 2 42 Birgit ANTONITSCH Hubert GRESSL Entwicklung von ISO 9000 Gudrun EGGER CMM Eine Einf hrung Katharina FRITZ Marina GLATZ Zeitmanagement im individuellen Software Entwicklungsprozess unter spezieller Ber cksichtigung schulischer Aspekte Johannes WERNIG PICHLER Mario LASSNIG Objektorientierte Software Metriken Michael JAKAB Michael OFNER Die Goal Question Metric Methode Ich ersuche die Vortragszeit von max 15 min strikt einzuhalten und die Folien bis Montag 24 Mai 2004 bzw 8 Juni 2004 jeweils Mittag in CLAROLINE abzulegen damit uns auch m glichst viel Zeit f r Diskussion erhalten bleibt 158 159 8 05 8 45 9 25 8 05 8 45 9 25 8 05 8 45 9 25 Seminar aus Angewandter Informatik Sommersemester 2004 R Mittermeir Programm der 1 Bakkalaureatsvortr ge 15 Juni 2004 SR 2 42 Kerstin J RGL Management of Requirements Traceability Problems Daniela ESBERGER Aufwandssch tzung am Beispiel COCOMO II Ingrid UNTERGUGGENBERGER Akzeptanztests Programm der 2 Bakkalaureatsvortr ge 22 Juni 2004 SR 2 42 Mario GRASCHL Qualit tssicherung bei agiler Software Entwicklung Edmund URBANI Metriken zur statischen Anal
34. Normalisation Das Europ ische Komitee f r Normung wurde 1961 in Paris gegr ndet 1975 wurde der Hauptsitz das CEN Management Center nach Br ssel verlegt und bekam den Status eines eingetragenen Vereines nach belgischem Recht Im Dezember 2003 betrug die Anzahle der aktiven Komitees 281 Die Zahl der von diesen Komitees erstellten Normen betrug 6 772 im Dezember 2003 Das Ziel dieses Gremiums ist die Schaffung eines einheitlichen und modernen Normen werkes f r Europa Es besteht aber eine starke Zusammenarbeit mit der ISO da nur eine weltweit einheitliche Norm die gew nschten Vorteile bringt vgl www cenorm be 2 2 3 DIN Deutsches Institut f r Normung Dieses Institut wurde 1917 gegr ndet und hat sei nen Sitz in Berlin Es ist ein Verein nach deutschem Recht Auch die nationalen Normungsinstitutionen pflegen eine enge Kooperation mit den internationalen Normungsgremien Viele Normen werden so instituti onstibergreifend erstellt und bearbeitet Bei der DIN wird die Arbeit von 76 Normungsausschiissen die sich weiter in 3 306 Arbeitsaussch sse unterteilen erledigt Diese Aussch sse haben seit der Gr ndung bereits 28 069 Normen ver ffentlicht vgl www din de 2 3 Entwicklung Zu Beginn der sechziger Jahre entstanden in gro Ben Unternehmen eigene Abteilungen zur Qualit tssicherung Deshalb begann parallel dazu die Arbeit an der Entwicklung von Standards und Normen f r Qualit tsmanagement Die ersten Standards ent
35. Projektgruppen an unterschiedlichen Standorten arbeiten Dies stellt eine Herausforderung f r die gesamte Projektentwicklung dar Eine besonders betroffene Phase der Projektentwicklung stellt dabei die Requirements Engineering Phase dar Dies ist die Phase der Anforderungsermittlung Auf den Anforderungen basiert das gesamte Projekt Somit ist der Erfolg des gesamten Projektes von den Ergebnissen der Requirements Engineering Phase abh ngig Deshalb ist es wichtig sich damit auseinander zu setzen welche Probleme die geographische Distanz der verschiedenen Projektteams hervorruft Diese Arbeit wird etliche Probleme auflisten die dabei zu l sen sind und soweit vorhanden L sungsm glichkeiten aufzeigen 2 Probleme Dieser Abschnitt befasst sich mit der Definition der Probleme die in globalen Projekten in der Requirements Engineering Phase auftreten 2 1 Kommunikationsbarrieren Durch geographische Distanz entstehen Schwierigkeiten w hrend der Requirements Engineering Phase Diese Phase erfordert verglichen mit anderen Phasen berdurchschnittlich viel Kommunikation blicherweise werden in vielen pers nlichen Treffen der verschiedenen Stakeholder die fachlichen und technischen Anforderungen des Projektes ermittelt Bei globalen Projekten muss f r jede Kommunikation auf technische Hilfsmittel zur ckgegriffen werden Bei Kommunikation mit Hilfe von technischen Hilfsmitteln geht ein Teil der nonverbalen Information ver
36. Prozess dadurch zwangsl ufig ein agiler Prozess wird Ein agiler Prozess muss folgend Charakteristika aufweisen 11 e Modularit t des Entwicklungsprozesses e Iteration ber den Entwicklungsprozess erm glicht schnelle Fehlererkennung und behebung e Zeitliche Beschr nkung der Iteration von einer bis zu sechs Wochen e Sparsamkeit im Entwicklungsprozess ent fernt alle unn tigen Aktivit ten e _Anpassungsf hig Inkrementeller Prozess Nicht auf den Prozess sondern auf die Be teiligten orientiert e Teamarbeit Zusammenfassend kann gesagt werden ein agiler Prozess ist inkrementell kooperativ Kunden und Entwickler arbeiten ber die gesamte Projektdauer zusammen einfach schnell anzuwenden leicht zu erlernen und adaptierbar 8 30 159 3 2 Agile Methoden Im Folgenden werden ein paar agile Methoden kurz vorgestellt und auf deren Qualit tssicherungs ma nahmen eingegangen Extreme Programming wird eigens in einem Kapitel n her behandelt 3 2 1 Scrum Scrum wurde das erste Mal in einen Artikel von Takeuchi und Nonaka 1986 14 erw hnt Dort wurde es als adaptiver schneller und selbstorganisierender Produktprozess vorgestellt Der Begriff Scrum kommt aus dem Rugby und bezeichnet die Strategie einen Ball wieder ins Spiel zu bringen Schwaber und Beedle 15 begr ndeten Scrum als agilen Softwareentwicklungs prozess Scrum hat drei Phasen Vorspiel Entwicklung und Nachspiel wobei die Vorspielphase in zwei Ph
37. Sicherheitsanalyse bzw safety analysis dient hierbei unter anderem zur Erhaltung der Vollst ndigkeit und soll als kontinuierlicher Proze w hrend der Requirement Analyse erfolgen Weiters sollen durch die Analyse Gefahren durch Fehler im System vermieden werden zumindest verringert und Risiken f r jedes einzelne Stadium des Lifecycles gesenkt werden Im April 1998 ver ffentlichte die MIRA einen C Regelsatz zur Best Practice Software Entwicklung innerhalb der Automobilbranche Diese beinhaltet 93 Regeln und 34 Richtlinien zur Erreichung hoher Automatisierbarkeit fiir sicherheitskritische Anwendungen Mit der Vorgabe von SIL3 Safety Integrity Level nach IEC 61508 kann unter anderem Konsistenz gew hrleistet werden So konnte ein portabler Code fiir embedded Systems geschaffen werden der ffentlich zug nglich ist 14 Das hier angesprochene SIL stellt f r Anlagen und Prozesse einen internationalen Sicherheitsstandard dar Diese Risiko bzw Sicherheitsanalyse erm glicht die Festlegung des so genannten Safety Integrity Level nach IEC 61508 International Electrotechnical Commission Dieses wird in 4 Levels eingeteilt die jeweils das Schadensausma von auftretenden Fehlern bestimmen e Level 4 Unkontrollierbar Fehler deren Effekte nicht kontrollierbar sind e Level 3 Schwer kontrollierbar Effekte normalerweise vom Benutzer nicht kontrollierbar aber k nnten durch Spezialisten kontrolliert werden e Level 2 Lahme
38. Stunden f r den Infor matikunterricht vorsieht Lehrplan Informatik unter http www bmbwk gv at medienpool 7037 Informatik Oberstufe pdf Literatur 1 Humphrey Watts S Introduction to the Personal Soft ware Process Addison Wesley Publishing Company 2002 2 Humphrey Watts S Managing the Software Process Addison Wesley Publishing Company 1990 3 Ricketts Ian W Software Projektmanagement kom pakt Springer 1998 4 Thaller Georg Erwin Softwareentwicklung im Team Galileo Press Bonn 2002 127 159 Testen komponentenbasierter Software Thomas FRANK Matr Nr 0060762 thomas frank edu uni klu ac at Abstract In die komponentenbasierte Software Entwicklung werden hohe Erwartungen gesteckt Signifikant gerin gere Entwicklungskosten und kiirzere Entwicklungszei ten werden erhofft Schlie lich sollen die wiederver wendeten Komponenten zu einer h heren Software Qualit t beitragen Dem Testen kommt hier eine be sondere Bedeutung zu Schwierigkeiten wie das Fehlen des Sourcecodes der Spezifikationen und oder der detaillierten Requirements erfordern neue Modelle die teilweise auf klassische Test Verfahren aufbauen teil weise aber an das Problem auf eine neue Art und Wei se herangehen In der vorliegenden Arbeit werden einige Ans tze besprochen wie das Testen komponentenbasierter Software durchgef hrt bzw erleichtert werden kann Eingegangen wird dabei auf eine s
39. Tes ten komponentenbasierter Software ist oft das Nicht vorhandensein des Quellcodes F r User von COTS Komponenten besteht eine verzwickte Lage Auf der einen Seite stehen Einsparungen von Kosten bzw Verk rzung der Entwicklungszeit andererseits ben ti gen sie zur Sicherstellung der Qualit t der Komponen ten aber Informationen die die Hersteller der Kompo nenten nicht weitergeben k nnen um auf dem Markt nicht geistiges Eigentum und somit vielleicht entschei dende Wettbewerbsvorteile an die Konkurrenz zu ver lieren Besonders deutlich tritt dies bei sicherheitskriti schen System hervor Die Frage ist hier auch wie Kun den trotz des Schutzes geistigen Eigentums von einem erreichten berdeckungsgrad berzeugt werden k n nen Black Box Testen Voas 7 meint der White Box Test ist aufgrund des Mangels an Informationen ber das Systems auszuschlie en Er schl gt drei Techniken vor e Reines Black Box Testen Anhand der am h ufigs ten auftretenden Szenarien wird das korrekte Ver halten der Komponente gepr ft Dieser Ansatz hat allerdings einige Nachteile Eine sehr gro e Zahl von Tests muss durchgef hrt werden um die Ver l sslichkeit der Komponenten absch tzen zu k n nen Falls keine automatisierte Bewertung des Testoutput m glich ist kann dieser Ansatz sehr teuer werden e System Level Fault Injection Dieser Ansatz pr ft die Auswirkungen abnormalen Verhaltens der Komponenten auf das Gesamtsystem Dies
40. Verhalten des einen auf das Verhalten des anderen schlie en Analogien werden eingesetzt um Vertrautheit mit einem Konzept auf ein anderes zu bertragen Ein Beispiel w re das heute weit verbreitete Konzept von Drag and Drop jedem Benutzer ist intuitiv 76 159 verst ndlich wie man einen Gegenstand nimmt und bewegt Ein Piktogramm lateinisch pictum Bild griechisch gr phein schreiben ist ein einzelnes Bildsymbol das eine Information durch vereinfachte grafische Darstellung vermittelt Piktogramme waren die Vorl ufer vieler fr her Schriftzeichen und wurden sp ter h ufig zu Logogrammen weiterentwickelt Einige Piktogramme werden heute noch im Japanischen bzw Chinesischen verwendet Ein Piktogramm sollte kultur und bildungsneutral sein also f r Menschen der ganzen Welt und unterschiedlicher Bildung verst ndlich sein Es darf keine Tabus verletzen das hei t keine religi se sittliche oder rassistische Diskriminierung darstellen Ein Piktogramm muss lesbar sein und die Information leicht zug nglich machen a JG g Der Ausdruck Icon deutsch Ikone griechisch eikon Bild bezeichnet im Computerbereich ein Piktogramm oder eine kleine Grafik Icons sind Versinnbildlichungen von Befehlsfolgen und gestatten dem Anwender Programme mit geringem Vorwissen einzusetzen Hinter dem Icon verbirgt sich ein Link der ein Programm ausf hrt oder es erm glicht zwischen Webseiten zu navigieren Im Gegensatz zu Blickf nger
41. Zusammenarbeit zwischen den Klassen gemessen werden Als Grenzwert wird 20 vorgeschlagen 4 2 3 Klassenvererbung Abstrakte Klassen existieren um Reuse von Methoden zu erm glichen und Daten unter ihren Subklassen festzulegen Die Anzahl von abstrakten Klassen im System ist ein An zeichen f r den erfolgreichen Gebrauch von Vererbung Num ber of abstract classes z hlt die Anzahl dieser Klassen im System Der Grenzwert wird mit zehn bis f nfzehn Prozent der Gesamtanzahl an Klassen im System angegeben 4 2 4 Methodenvererbung Diese Gruppe von Metriken untersucht die Superklassen Subklassen Vererbungsbeziehungen Die Metrik Number of methods inherited by a subclass soll hierbei ein Indikator f r die St rke des Einsatzes des Subklassenkonzepts sein Lorenz und Kidd legen f r diese Metrik keinen Grenzwert fest geben aber an dass der Prozensatz an vererbten Me thoden hoch sein sollte Die allgemeine Funktion einer Subklasse n mlich dass es den Objekttyp der Superklasse weiter spezialisiert wird von der Metrik Number of methods added by a subclass wiederge spiegelt Die Anzahl neuer Methoden sollte dabei normaler weise fallen je tiefer hinunter in der Hierarchie man geht Als unterer Grenzwert wird 1 angegeben Der obere Grenz wert stellt eine absteigende Skala dar F r den ersten Level der Verschachtelung wird ein Wert von 20 angef hrt f r den Level sechs welcher der h chste Verschachtelungslevel sein sollte ein Wert v
42. aufrufen sollte Die folgenden Mutationsoperatoren verdeutlichen diesen Aspekt 141 159 OMR Overloading method contents change OMR berpr ft den zweckm igen Aufruf von berladenen Methoden Dabei werden Methodenr mpfe gleichnamiger Methoden mit unterschiedlichen Signaturen vertauscht d h mittels this wird in einer berladenen Methode eine namensgleiche Methode aufgerufen 6 OMD Overloading method deletion Dieser Mutationsoperator l scht berladene Methodendeklarationen Sollte der Mutant trotzdem korrekt arbeiten kann dies auf eine inkorrekte Verwendung der berladenen Methode hinweisen 6 Au erdem kann die Nicht Verwendung von Methoden aufgedeckt werden 9 OAO Argument order changel OAO vertauscht die Parameter von Methodenaufrufen berladender Methoden falls kompatible Methodensignaturen vorhanden sind Er berpr ft die richtige Verwendung von Methodenaufrufen die durch ungewollte Parametertypkonvertierungen f r den Programmierer richtig erschienen sind 9 OAN Argument number change ndert die Anzahl der Argumente bei den Aufrufen von berladenen Methoden wenn eine Methode vorhanden ist die die neue Argumentliste akzeptiert Dies untermauert die Richtigkeit des Methodenaufrufes 6 Spezifische Merkmale von Java JTD this keyword deletion JTD l scht die Verwendung des Schl sselwortes this welches erlaubt versteckte Instanzvariablen in einer Methode zu re
43. ber der Vorversion nicht entsprechen Eine optimale Freigabe Politik kann man unter vielen Gesichtspunkten betrachten Beruhend auf Kostenkriterien Zuverl ssigkeitskriterien wie auch ein Mix der Zuvorgenannten unter Ber cksichtigung der Effizienz 3 2 Technische Aspekte Software Reliability Growth Models sind deshalb entwickelt worden und den optimalen Zeitpunkt bestimmen zu k nnen um mit dem Testen aufzuh ren 4 Software Reliability Growth Models 4 1 Begriffsbestimmung 4 Man spricht von einem Software Failure wenn das Verhalten der Software von dem seiner Spezifikation abweicht Es handelt sich dabei um das Resultat eines Software Fault Man kann zwei Aktivit ten in Bezug bringen mit der Zuverl ssigkeits Analyse Estimation Absch tzung und Prediction Prognose Das Erstere funktioniert r ckschauend und wird ausgef hrt um von einem Punkt in der Vergangenheit die erreichte Zuverl ssigkeit in der Jetztzeit zu erfahren Die Prognose andererseits parametrisiert Reliability Models um zuk nftige Zuverl ssigkeiten vorherzusehen 4 2 Modelle Im Allgemeinen kann man Software Reliability Models klassifizieren in Black Box und White Box Modelle Der Unterschied ist einfach der dass White Box Models die Struktur der Software betrachten um eine Aussage ber deren Zuverl ssigkeit zu treffen Black Box Models tun dies hingegen nicht 4 2 1 Black Box Software Reliability Models Alle SRGMs sind von diesem Typ so
44. bereits an mehreren hnlichen Projekten mitgearbeitet hat dann haben die vorgeschlagenen Sch tzwerte im All gemeinen eine hohe Genauigkeit Andernfalls k nnen die ermittelten Sch tzwerte weit entfernt von den k nf tigen Istwerten liegen Sind mehrere Experten beteiligt kommt es zu ver schiedenen Ergebnissen die auf einen Endwert ge bracht werden m ssen Um ein gemeinsames Resultat zu erreichen gibt es zwei M glichkeiten Einerseits kann ein Mittelwert errechnet werden Hier k nnen Extremwerte allerdings zu einer Verschleierung f h ren Andererseits kann in einer Diskussion in die alle Experten miteingebunden werden ein einheitliches Ergebnis gefunden werden Eine herk mmliche Be sprechung wo alle Experten zusammenkommen und sich auf eine L sung einigen sollen hat aber markante Nachteile Mitglieder k nnen leicht durch wortge wandtere Personen mit mehr Durchsetzungskraft oder Autorit t in den Schatten gestellt werden Um dies zu vermeiden wurde die Delphi Methode entwickelt die in verschiedenen Bereichen einsetzbar ist Kurz zu sammengefasst funktioniert die Delphi Methode wie folgt Die Experten bleiben untereinander anonym Dadurch k nnen pers nliche Faktoren gr tenteils ausgeschlossen werden Eine Monitorgruppe holt die Meinungen der Experten ein und versucht durch eine Befragung dieser zu einem Ergebnis zu kommen Problematisch ist hier allerdings der hohe Zeitbedarf und so ist dies nur bei gro en Projek
45. bernehmen Kindklassen mehrere Methoden ihrer Elternklassen Wenn man eine Elternklasse stubben m chte muss man f r fast jede Elternmethode einen Stub schreiben e Assoziationsbeziehungen erfordern beim L schen hingegen meist nur einen sehr spezifischen Stub und stellen so die schw chsten Abh ngigkeiten zwischen Klassen dar Es gibt mehrere Algorithmen zum Aufl sen von Zyklen welche qualitativ unterschiedlich sind Die urspr nglich von Kung et al vorgeschlagene Methode 2 w hlt zuf llig eine zu l schende Assoziations beziehung was ein eher naiver Ansatz ist Wir wollen deshalb den Algorithmus von Briand et al 5 vorstellen der sehr gute Resultate bez glich der erforderlichen Stub Anzahl erzielt Abb 7 Zyklischer ORD 4 1 Aufl sen von Zyklen nach Briand et al Bei diesem Algorithmus werden rekursiv so genannte Strongly Connected Components SCCs ermittelt und von diesen die am besten geeignetste Assoziationsbeziehung gel scht Eine SCC ist ein Subgraph eines ORDs wobei f r alle Knoten u und v der SCC gilt u ist durch einen Weg mit v verbunden und umgekehrt SCCs werden durch den Algorithmus von Tarjan 6 gefunden 135 159 Innerhalb einer SCC werden alle darin vorhanden Assoziationsbeziehungen mit der Formel As A B Bin 3 Aout gewichtet Bin bezeichnet die Anzahl der eingehenden Kanten der Klasse B Asu die Anzahl der ausgehenden Kanten der Klasse A Die Kante mit dem h chsten Wert wird
46. dar ber hinaus bei speziellen Methoden wie ETHICS sogar ber die gesamte Dauer des Projekts hinweg Dieses Einbeziehen ist ein zunehmender Trend und dies zu Recht denn es ist viel leichter die W nsche der Benutzer zu erf llen als ihre Bed rfnisse vorherzusagen vorausgesetzt die Benutzer sind auch willig sich zu beteiligen und erhalten von ihren Vorgesetzten die n tige Zeit dazu F r das genaue Verst ndnis der Benutzer und ihrer W nsche ist es n tzlich sie in unterschiedliche Gruppen einzuteilen M glichkeiten hier w ren Studenten Manager Kinder Behinderte Frauen M nner Lehrer rzte und viele mehr Hat man alle Beteiligten erkannt kann man festlegen wen man wie behandeln will sei es ihre W nsche zu erf llen unwichtige Benutzer zu ignorieren und feindliche Benutzer unfreundlich zu behandeln 5 Diese Einteilung ist zwar meist mangelhaft da Benutzer sich selbst innerhalb dieser Gruppen stark individuell verhalten aber eine unzureichende Einteilung ist immer noch besser als gar keine Unterschiede finden sich auch in der Erfahrung der Benutzer die sich nur schwer auf einer linearen Skala messen l sst Einerseits ist hier zwischen allgemeiner Erfahrung mit Programmen und ihren Aufgaben und andererseits zwischen spezieller Erfahrung mit einem bestimmten Programm und hnlichen Produkten zu unterscheiden Diese Eigenschaften sind bei der Entwicklung von Programmen zu bedenken zielt es auf Benutzer mit unterschiedl
47. den Beginn und das Ende sowie die Nettozeit also die Zeit ohne Un terbrechungen der Bearbeitung eines Problems schrift lich festzuhalten Interruption Delta Time Activity Comments Lecture Read text Ch 182 X Assignment 1 break chat Lecture Text Ch 3 Chat with Mary X Assignment 3 X Text Ch 4 Quiz prep break phone chat base Laa Abb 5 2 Time Recording Log Zum besseren Verst ndnis des Time Recording Logs wird der Eintrag am 10 September genauer er l utert Neben dem Datum dem Beginn und dem Ende der Aktivit t werden allf llige Unterbrechungen hier 6 5 Minuten sowie die Art der Unterbrechung angef hrt Die Nettozeit sowie die Art der Aktivit t sind ebenfalls aufzulisten Durch das x und die 1 erf hrt man dass genau ein Kapitel erfolgreich fertig gestellt wurde 5 1 3 Periodenpl ne Ausgehend vom Time Recor ding Logbuch k nnen die darin gesammelten Daten zur Erstellung von Periodenpl nen genutzt werden Die Hauptaufgabe von Periodenpl nen ist die bersicht liche Darstellung der Zeit die man innerhalb einer Pe riode z B einer Woche f r die einzelnen Aktivit ten ben tigt Ausgehend von Abbildung 5 2 l sst sich die Weekly Activity Summary aus Abbildung 5 3 erstellen So werden z B unter Montag die Vorlesungszeit die Programmierzeit und die Lesedauer ersichtlich aus dem Time Recording Log verzeichnet 11 Period T
48. den Prozess relevante Technologien In der SEA wird der Softwareprozess in kleine definierte Einheiten Tasks unterteilt wobei f r jeden Task dessen Vorbedingungen Funktionalit t und ausf hrende Organisationseinheit dokumentiert werden 5 4 3 Stufe 3 Defined Auf Stufe 3 sind die wesentlichen Voraussetzungen f r einen erfolgreichen Softwareprozess bekannt und werden organisationsweit erf llt Der Prozess der Organisation ist als Standard definiert und in sich konsistent 1 Individuelle Prozessaktivit ten sind sichtbar da eine SEA eingef hrt wurde Alle Projekte basieren auf demselben Standardprozess wobei jede Abweichung von diesem bewilligt und dokumentiert werden muss Zus tzlich wird ein Risikomanagement eingef hrt das sich damit besch ftigt Risikobereiche innerhalb des Softwareentwicklungsprozess zu identifizieren und geeignete Ma nahmenpl ne auszuarbeiten 5 Folgende SPBs sind Stufe 3 zugeordnet Der Organisationsweite Prozessfokus befasst sich wie die Organisationsweite Prozessdefinition mit dem Sammeln und bertragen der Prozessverbesserungen und besten Praktiken auf andere Projekte und die gesamte Organisation Das Trainingsprogramm ist ein SPB der Stufe 3 doch f hren Organisationen auf allen Reifegraden Trainings durch Sp testens auf Stufe 3 sollte aber ein effektives organisationsweites Trainingsprogramm vorhanden sein Auf Stufe 2 befassten sich die Softwareprojektplanung und die Softwa
49. der Benutzung von Programmen dieser Art Ist das Programm ein Folgeprogramm eines ihm bekannten ist von Anfang an Vertrautheit gegeben Handelt es sich hingegen um eine v llig neue Benutzeroberfl che ist das Erlernen dieses Programms Voraussetzung f r seine Benutzung Auf dem Weg zum Lernen passiert eine Information zuerst das Kurzzeitged chtnis um dann in das Langzeitged chtnis zu gelangen Das Kurzzeitged chtnis ist in der Lage sich ber einen Zeitraum von bis zu drei ig Sekunden 7 2 Dinge zu merken Werden mehr Elemente aufgenommen gehen die ltesten Elemente zugunsten der Neuen verloren Das Langzeitged chtnis im Gegensatz dazu bietet eine unbegrenzte Kapazit t daf r ist der Zugang dazu weniger verl sslich die Speicherzeit variiert von acht Sekunden bis zu mehreren Jahren Das Abrufen von Informationen aus dem Langzeitged chtnis ist abh ngig von Assoziationen bei Erleben von mit einer Erinnerung in Verbindung stehenden Reizen f llt der Zugriff auf das Langzeitged chtnis leichter Dies l sst sich durch den Einsatz von vertrauten Bildern und Elementen n tzen und in dem Entwurf von Benutzerschnittstellen werden vertraute Bilder wie Abbildungen von Disketten Druckern oder Papierk rben eingesetzt Die Zufriedenheit der Kunden sollte aus Gr nden des eigenen berlebens jedem Entwickler am Herzen liegen Sie unterliegt einem st ndigen Wandel und muss gemessen werden um die eigene Position zu bestimmen Wichtig
50. der Ergebnisse dieser Testf lle Die Ausliefe rung Installation und Verantwortlichkeiten des Schl sselpersonals sind im Akzeptanztest inbegriffen Der K ufer sollte die Tests selbst entwickeln um sicherzustellen dass das zu liefernde Produkt den Anforderungen und Betriebszielen entspricht und sich nicht auf die Testf lle und ergebnisse des Verk ufers verlassen Allerdings sollten diese Akzeptanztests vom Verk ufer reviewed werden und beide der K ufer und der Verk ufer m ssen der Korrektheit der Tests zu stimmen Des Weiteren muss ein Prozess festgelegt werden um Probleme die w hrend des Akzeptanztests auftauchen zu l sen Das umfasst die Problemidentifi kation verfolgung und die Auslieferung von festge setzten Software Versionen um Verz gerungen und Verwirrung an kritischen Punkten zu vermeiden Der Vertrag sollte die Verantwortlichkeiten zwi schen K ufer und Verk ufer in Bezug auf den Akzep tanztest festlegen Das Software Prozess Handbuch dieses definiert den Software Entwicklungsprozess des Verk ufers sollte Abnahmetests als eine eigene Entwicklungsstufe beinhalten Dieses sollte in den Allgemeinen Bedingungen die Aktivit ten die w h rend des Akzeptanztests auftreten identifizieren und sich nicht so sehr auf die Tests selbst konzentrieren da diese im Verantwortungsbereich des K ufers liegen sondern eher auf die Unterst tzung die der Verk ufer dem K ufer w hrend dieser Phase eventuell erweisen
51. der Kunde nicht mit einbezogen wird Da die Inspektion die mein Hauptthema darstellt zu der Gruppe der Reviews z hlt die den Kunden nicht mit einbeziehen werde ich nur diese ausf hrlicher behandeln Management Reviews dienen der formellen Bewertung des Projektplans oder auch um zu l V amp V Die st ndige Kontrolle w hrend der Entwicklung von Software um sicherzustellen dass das Produkt seinen Spezifikationen entspricht und auch korrekt funktioniert berpr fen inwieweit der Projektstatus dem Projektplan folgt wobei entschieden wird ob und wie etwas durchgef hrt wird Sie werden blicherweise im Projektplan zu bestimmten Zeitpunkten des Software Life Cycle festgelegt beispielsweise w hrend der Analysephase der Entwurfsphase Technische Reviews werden eingesetzt um einen konkreten Bestandteil der Software zu bewerten die bereinstimmung von Spezifikation oder Standards mit dem Softwareprodukt selbst zu berpr fen und auch um Fehler zu finden Inspektionen weisen eine hohe hnlichkeit zu Technischen Reviews auf Auch sie werden verwendet um Fehler in fr hen Stadien der Softwareentwicklung zu finden und ein Softwareprodukt im Hinblick auf die Einhaltung von Standards und Vorgabedokumenten wie etwa das Anforderungsdokument zu berpr fen Der Ablauf von Inspektionen ist formaler und erlaubt den direkten Vergleich zu Normen und Standards Walkthrough Ein Unterschied zur Inspektion liegt darin dass die Rolle
52. der Software Anteil selbst im wachsen ist Immer mehr Fehler treten in den eingebauten Systemen auf und verursachen so horrende Kosten Der Grund daf r ist nicht schwer zu finden In punkto Sorgfalt und Gr ndlichkeit ist der Ruf von Ingenieuren in dieser Branche noch heute besser als der der Programmierer was gerade durch solche fehlerhaften Modellreihen noch unterstrichen wird Entwicklung der offiziellen R ckrufaktionen bei Kraftfahrzeugen 113 19 1993 1994 1995 1996 1997 1998 1999 2000 2001 Abbildung 2 Anzahl der R ckrufaktionen 25 Um nur einige Beispiele aufzuzeigen die von Fachzeitschriften wie Autotouring oder auto motor und sport in den letzten Jahren ver ffentlich wurden Renault musste rund 265 000 Kangoo wegen Probleme bei dem Bord Rechner zuriickrufen da dieser unbeabsichtigt den Airbag ffnete Und auch die DaimlerChrysler Corporation musste Sch den in Milliardenh he zahlen als Fahrzeugeigent mer in den USA sie wegen defekter Airbags verklagte General Motors rief 127 000 Sportwagen der Marke Chevrolet Corvette wieder zur ck da die automatischen Lenkschl sser ein Blockieren des Lenkrades verursachen konnten Peinlich war des Weiteren ein TDI von Volkswagen der wegen eines Defektes bei der Elektronik nicht abgestellt werden konnte da die Spritzzufuhr nach dem Abziehen des Z ndschl ssels nicht unterbrochen wurde Diese Ereignisse von denen jetzt nur ein Ausschnitt erw hnt wurde zeugen von
53. die Erreichung des n chsten Reifegrades werden Ma zahlen eingef hrt die Aufschluss ber die Effizienz des Prozesses geben F r jeden Prozessschritt muss festgelegt werden welche Kosten durch ihn entstehen bzw wie dessen Qualit t gemessen werden kann Zu diesem Zweck m ssen vorab Kennzahlen f r die Qualit tsbewertung definiert werden Weiters 99 159 werden die Kosten f r die Korrektur eines fehlerhaften Prozessschrittes spezifiziert 5 4 4 Stufe 4 Managed Eine Organisation der Stufe 4 steuert die Softwareentwicklung Auf dieser Stufe werden die Qualit t der Produkte und die Produktivit t der Prozesse durch ein organisationsweites Metrikprogramm quantitativ gemessen Dies dient zur vorausschauenden Projekt und Organisations steuerung Durch die umfassenden Prozessmessungen und die darauf aufbauenden Analysen k nnen die Produktqualit t sowie der Entwicklungsprozess kontinuierlich verbessert werden F r die Organisation ist der Fortschritt zu Reifegrad 4 mit hohen Kosten f r die Metrikerfassung und Verwaltung verbunden Um die G ltigkeit der Metriken sicherzustellen m ssen einheitliche Kriterien f r die Datenerfassung festgelegt werden damit den Bewertungen und Analysen keine invaliden Daten zugrunde liegen 5 Es gibt nur zwei SPBs der Stufe 4 Das Quantitative Prozessmanagement betrifft die Prozessqualit t und die Messung der Prozessleistung Es dient dazu besondere Ursachen von Abweichungen im Sof
54. die Fahigkeiten der Projektanalytiker PCAP Programmer Capability die Fahigkeit der Programmierer PCON Personal Continuity die Personalkontinuitat APEX Applications Experience die Erfahrungen der Analytiker auf dem Ge biet des Projektes PEXP Platform Experience die Erfahrung der Programmierer auf dem Gebiet des Projektes LTEX Language and Tool Experience die Erfahrung mit der Sprache und den Werkzeugen Projektattribute TOOL Use of Software Tools die Verwendung von Softwarewerkzeugen SITE Multisite Development die Anzahl der Arbeiten die an mehreren Stellen ausgef hrt werden und die Kommu nikation zwischen diesen Stellen SCED Required Development Schedule die Komprimierung des Entwicklungsplans Wie auch beim Early Design Model k nnen diese Gr en bewertet werden und ihre Produktsumme er gibt wiederum den Multiplikator M Die Werte sind folgender Tabelle zu entnehmen BOEH00 Tabelle 5 Cost Driver beim Post Architecture Model z RELY 0 82 0 92 1 10 1 26 n a DATA n a 0 90 1 14 1 28 n a CPLX 0 73 0 87 1 17 1 34 1 74 RUSE n a 0 95 1 07 1 15 1 24 DOCU 0 81 0 91 1 11 1 23 n a TIME n a n a 1 11 1 29 1 63 STOR n a n a 1 05 1 17 1 46 PVOL n a 0 87 1 15 1 30 n a ACAP 1 42 1 19 0 85 0 71 n a PCAP 1 34 1 15 0 88 0 76 n a PCON 1 29 1 12 0 90 0 81 APEX 1 22 1
55. die abh ngig von 10Sie sind theoretisch wie die meisten OO Metriken auch auf ein ausreichend detailliertes Design anwendbar 111m Gegensatz zu CBO ist die hier verwendete Kopplung nicht symmetrisch 12Martin verwendet eigentlich in Anlehnung an Booch den Begriff Class Category Package dr ckt das gleiche aus und ist heute nach Ansicht des Autors gel ufiger 62 159 Abstraction Instability 1 Abbildung 2 Martin s Main Sequence Klassen innerhalb des Packages sind Efferent Coulpings Ce Anzahl der Klassen im Package die von Klassen au erhalb des Packages abh ngen Instability I I Ce Ca Ce wobei I 0 maximale Stabilit t und 1 maximale Instabilit t bedeutet Abstractness A Die Abstraktheit ist der Anteil abstrakter Klassen am Package A 0 bedeutet keine abstrakte Klassen A ausschlie lich abstrakte Klassen 1 Martin setzt Abstraktheit und Instabilit t in Beziehung Packages mit hoher Stabilit t sollen auch abstrakt sein damit sie ideal erweiterbar sind Im Gegensatz dazu sollten instabile Packages m glichst konkret sein Packages die auf der Linie zwischen diesen beiden Extremen liegen der sogenannten Main Sequence siehe Abb 2 entsprechen Martin s Idealbild Letztendlich definiert er noch die Metrik Distance D A J 1 2 die die Entfernung von der Main Sequence angibt Im besten Fall ist D 0 im schlechtesten Fall ist D
56. die externen Merkmale von Klassen Im folgenden wird zu jedem dieser Bereiche zumindest eine Metrik aufgef hrt 4 2 1 Methodengr sse Eine Metrik die sich auf die Methodengr e bezieht ist Number of message sends welche die Anzahl von in der Methode gesendeten Nachrichten misst Dabei k nnen die Nachrichten die Typen Unary Das sind Nachrichten ohne Argumente Binary Nachrichten mit einem Argument ge trennt durch einen speziellen Selektor Beispiele sind String konkatenation und mathematische Funktionen oder Key word Nachrichten mit mehr als einem Argument haben Diese Metrik soll die Klassengr e auf eine relativ unbefan gene Art messen Eine gro e Anzahl von Nachrichten kann auf funktionsorientierte Programmierung hindeuten Der Grenzwert f r diese Metrik wird mit dem Wert 9 angegeben Number of statements ist eine weitere Metrik die die Metho dengr e misst Was als Anweisung bezeichnet wird h ngt nat rlich von der Programmiersprache ab Als Grenzwert wird der 0 8 fache Wert vom Number of message sends Grenzwert angef hrt 4 2 2 Klassengr sse Metriken wie Number of instance methods in a class Num ber of instance variables in a class oder Number of class variables in a class werden dazu verwendet einzelne Klassen zu beurteilen Die Metrik Number of instance methods in a class z hlt alle ffentlichen gesch tzten und privaten Me thoden die f r eine Klasse definiert sind Damit soll der Grad der
57. diese Technik ein Selbstverst ndlich sind computerunterst tzte Qualit tstechniken wie unter anderem Modultests oder statische Analysetools unverzichtbar aber nach wie vor sind die Kollegen eines Softwareentwicklers die idealen Pr fer wenn es darum geht Fehler in Dokumenten oder Programmen zu finden In dieser Arbeit werde ich den Einsatz der Formalen Inspektion als Mittel der Qualit tssicherung f r Softwareprodukte genauer betrachten Um die Grundlagen einer Inspektion auch verst ndlich zu machen werde ich zuerst kurz das Review allgemein erkl ren wobei ich insbesondere dessen Ziele und Ergebnisse den Unterschied zwischen einem Review und einem Test und die verschieden Review Arten behandeln werde Nachdem die grundlegenden Dinge erw hnt wurden folgt des Hauptthema Die Formale Inspektion Zu Beginn dieses Abschnittes werde ich den Unterschied zwischen den vier existierenden Inspektionsarten erkl ren Danach vertiefe ich mich in das Thema der Formalen Inspektion wobei ich mit der Zusammensetzung eines Inspektionsteams und deren genauem Ablauf beginnen werde um dem Leser eine Vorstellung geben zu k nnen wie eine solche Inspektion berhaupt vor sich geht Weiters werde ich darauf eingehen wie die Fehler die durch eine Inspektion aufgedeckt werden kategorisiert werden was man unter der optimale Inspektionsrate versteht und welche verschiedenen Lesetechniken bei der 19 159 Durchf hrung einer Inspektion einge
58. e Anti Crash Komplex Heute noch simple Abstandskontrolle per Radar bald schon exakte Laser Vermessung mit Software fiir automatisches Bremsen und Ausweichen e _Innenluftmanagement Eine Kombination aus Luftg te Sensoren und Filtern eliminiert Schadstoffe Das Lieblingsparfum kommt aus dem Zerst uber e Telematik Box St ndige Verbindung zu Mobilfunk Unternehmen die daraus Verkehrsfluss und Stau Daten errechnen e LED Frontscheinwerfer Leuchtdioden ersetzen langfristig die gewohnten Scheinwerfer Vorteil zuverl ssiger amp sparsamer e Sicherheits Programm Wenn Radar Laser und Sensoren echte Unfallgefahr wittern fahren die Sitze automatisch in Idealposition und die Gurte werden gestrafft e Automatische Notbremse Versch rftes Abstandsradar das eine Vollbremsung ausl st wenn ein Hindernis im Weg steht Ziel Unfallfolgen sollen vermindert werden e Nachtsichtsystem Fernlicht ohne Blendung W rmebild Kamera erkennt Hindernisse Bilder davon werden auf die Scheibe projiziert 26 Diese Zukunftsvisionen repr sentieren die neuen Sinnesorgane des Automobils und lassen so den menschlichen Fahrer fast berfl ssig werden Dies mag sehr viel versprechend klingen aber die traurige Wahrheit dahinter ist dass je mehr Innovationen umgesetzt werden desto mehr Fehlfunktionen werden auftreten und so eventuell mehr zu einem Laster werden als zu einer Unterst tzung So muss sich das Augenmerk in der kommenden Z
59. einem Programm ist da Anf nger den Wunsch haben alles leicht verst ndlich vorzufinden und Profis schnell Befehle eingeben wollen Beispielhaft hierf r w ren Einstellungen f r Anf nger und Fortgeschrittene oder die M glichkeit zwischen graphischer Benutzeroberfl che und Kommandosprache zu wechseln Aber Customizing muss sich nicht nur darauf beschr nken dem Benutzer M glichkeiten zu geben die Benutzerschnittstelle seinen Bed rfnissen anzupassen Ein Programm kann auch das Verhalten eines Benutzers beobachten und aus seinen Aktionen auf sein Gedankenmodell und dessen Ausgereiftheit schlie en Meint das Programm den Benutzer und sein Gedankenmodell richtig einsch tzen zu k nnen kann es nun korrigierend reagieren und die Interaktionstiefe der Benutzerschnittstelle seinen F higkeiten anpassen Ein derartiges Verhalten des Programms ist nat rlich nur dann akzeptabel wenn der Benutzer einverstanden ist und es muss jederzeit auch f r unerfahrene Benutzer ein und ausschaltbar sein Wenn ein Benutzer nun an Erfahrung gewinnt wird sich das Programm anpassen und ein schnelleres und effizienteres Bedienen erm glichen Voraussetzung daf r ist selbstverst ndlich dass sich die Benutzer des Programms nicht st ndig ndern Customizing ob nun aktiv oder passiv ist f r jedes Projekt ob mit Benutzerbeteiligung oder ohne n tzlich da einzelne Benutzer sehr individuelle W nsche haben und so ein Maximum dieser erf llt werden ka
60. entwickeln was sich ja nicht von anderen Methoden der Softwareentwicklung entscheidet Allerdings werden bei XP nur kleine Teile entwickelt und dann zusammengef gt und nach jeder Iteration ein Treffen mit dem Kunden angesetzt um zu pr fen ob das System seinen Anforderungen entspricht bzw ob der Kunde mittlerweile zus tzliche Aspekte erkannt hat Der Vorteil von XP liegt darin dass es f r SW Projekte eingesetzt werden kann in denen noch nicht alle Anforderungen von vornherein klar spezifi ziert werden k nnen bzw f r Projekte deren Anforde rungen sich laufend ndern 17 4 Wie wird ein Akzeptanztest durchge f hrt In diesem Abschnitt werde ich eine Methode zur Durchf hrung eines Akzeptanztests vorstellen die William Perry in seinem Buch Effective Methods for Software Testing 11 auf den Seiten 238 bis 244 aus f hrlich beschreibt Sein Prozess besteht aus f nf Schritten die in Abbil dung 2 veranschaulicht werden STEP 1 STEP2 Define Buyer s Define The Role Acceptance Criteria STEP 3 STEP 4 STEP 5 Develop An Execute Acceptance Plan Acceptance Plan Decision Abbildung 2 Akzeptanztestprozess 11 4 1 STEP 1 Bestimme die Rolle des K ufers Verantwortlich fiir die Software Akzeptanz ist der K ufer in dessen Verantwortungsbereich auch die folgenden Punkte liegen e Sicherstellung dass der die Anwender in die Entwicklung der Anforderungen und der Ak zeptanzkriterien ei
61. erf hrst Du genauer wenn Du alles liest oder h rst enthalten Doch der Leserkreis ist ein anderer Es sind nicht die endg ltigen Leser Teilnehmer sondern die Juroren die insgesamt eine gute Veranstaltung zustande bringen wollen Somit sollte der durch 156 159 Extended gewonnene Raum dazu genutzt werden Gutachter davon zu berzeugen dass das was sie noch gar nicht lesen k nnen lesenswert w re der gesamte Beitrag ein positiver Beitrag zur Gesamtveranstaltung sein wird Letzteres ist wohl der entscheidende Punkt Wie er zu bew ltigen ist h ngt ein wenig von der jeweiligen Veranstaltung ab M glich w ren Kriterien wie Kann ein guter Aufsatz erwartet werden Langfrist Perspektive Ist es interessant innovativ Haben die Autoren das Potential und das Material ihre Versprechen einzul sen Kann ein guter Vortrag erwartet werden Kurzfrist Perspektive L sst die Qualit t der Pr sentation des Extended Abstracts auf die f r den Vortrag n tige Fokussierung und klare Strukturierung r ckschlie en Insbesondere f r letzteres gilt wie passt das zu Erwartende zum Gesamtprogramm wie passt es zur erwartenden restlichen Teilnehmerschaft ist es fokussiert ist es fundiert bzw wie ist es fundiert klingt es spannend ist es neu innovativ kreativ auch gute berblicksarbeiten sind nach diesen Kriterien beurteilbar daher auch was ist das Neue daran Inhalt Darstellung Som
62. her beleuchtet werden und mit COCOMO II dem Leser ein Werkzeug zur praktischen Anwendung geboten werden 1 Aufwandssch tzung Was man nicht misst das kann man nicht steuern Dieser Satz von Tom de Marco trifft den Nagel auf den Kopf Zu Beginn eines Softwareprojektes sind oft Fra gen ber den Arbeitsaufwand die Dauer die Kosten und die Anzahl der Mitarbeiter die f r die Durchf h rung des Projektes ben tigt werden durch den Projekt leiter zu kl ren Obwohl zu diesem Zeitpunkt genaue Informationen fehlen sollte dennoch eine m glichst pr zise Sch tzung vorgenommen werden da bei spielsweise aufgrund dieser Daten ein Angebot erstellt wird und dies weder zu hoch noch zu niedrig ausfallen darf Dies stellt nat rlich ein erhebliches Problem dar das mit Hilfe der verschiedenen Methoden der Auf wandssch tzung siehe Kapitel 1 2 gel st werden kann Aufwandssch tzung ist keine einmalige Aufgabe bei der Projektplanung sondern sollte regelm ig durchgef hrt werden um Abweichungen zu erkennen und um fr hzeitig entsprechende Ma nahmen zu er greifen SOMMO1 1 1 Kostenarten Bei Softwareprojekten unterscheidet man drei Ar ten von Kosten SOMMO01 Hardware und Softwarekosten Reise und Schulungskosten Personalkosten Die ersten beiden Punkte sind im Vergleich zu den Personalkosten nahezu zu vernachl ssigen Zwar k n nen speziell die Reisekosten bei Projekten die an ver schiedenen Standorten r
63. hrung als zB der NASA Uberschneidung bet Checklisten Fehlersuche viel Literatur und Ex perimente vorhanden Fehlerfindungskosten oft geringer als bei Checklisten 3 7 Wirtschaftlichkeit Die Inspektionsaufw nde sind abh ngig von der Projektdauer die mit der Verf gbarkeit des Materials beginnt und mit der Korrektur aller gefundenen Fehler endet und der erbrachten Leistung Diese Kosten schlie en die Trainingskosten des Personals die Management kosten die Vorbereitungs und Durchf hrungskosten der Sitzung und zus tzlich die Kosten der Fehlerkorrektur mit ein In der Regel nehmen durchschnittlich 4 5 Personen an einer Inspektion teil Sie ben tigen 1 2 Stunden f r die Vorbereitungen und weitere 1 2 Stunden f r die Sitzung Bei der Durchf hrung einer Code Inspektion erm glicht diese totale Leistung von 10 20 Stunden im Durchschnitt die Entdeckung von 5 bis 10 Fehlern in 250 500 Zeilen eines neuen ihnen vollkommen unbekannten Codes oder 1000 1500 Zeilen eines normalen ihnen schon bekannten aber eventuell erg nzten Codes O Neil 1995 Cost Units 8 10 During Design Before Code Before Test During Test In Production Abbildung 5 Relative Fehlerbehebungskosten 95 159 Der Nutzen dieses Prozesses beinhaltet eine Reduktion des Aufwandes f r die Neubearbeitungen Tests und Wartung Das Ersparnis ist umso h her je fr her ein Fehler im Softwareentwicklungsprozess gefunden wird
64. jedoch gezielt entwickelt werden Zertifizierungen zur Dokumentation von Qualit tsstandards gewinnen dadurch immer gr ere Bedeutung So bietet das Capability Maturity Model CMM bzw in der neuen Version das Capability Maturity Model Integrated CMMI gute Anhaltspunkte f r die Gestaltung einer erfolgreichen Softwareorganisation CMM konzentriert sich dabei auf die Prozesse die an der Herstellung von Software beteiligt sind Dahinter steht die Idee dass die Oualit t von Software wesentlich von den Entwicklungsprozessen der Hersteller abh ngt 1 Einleitung Sehr wenige Projekte enden in Budget und Zeit mit der versprochenen Funktionalit t Um Qualit t bei Softwareprojekten zu erreichen bietet das CMM Model einen Zertifizierungsstandard Das Capability Maturity Model f r Software entstanden am Software Engineering Institute SED an der Carnegie Mellon University in Pittsburgh Pennsylvania wird weltweit angewendet um die Art und Weise der Softwareherstellung und Wartung zu verbessern Das CMM hat seinen Ursprung in einem Auftrag des Department of Defence DoD das die mangelnde Qualit t von Softwareprojekten in den Griff bekommen wollte Unter der Leitung von Humphrey Watts begann das SEI im Auftrag vom DoD 1986 mit der Entwicklung eines Fragebogens mit dessen Hilfe die Leistungsf higkeit von Softwarelieferanten bewertet werden sollte Fortw hrende berschreitungen von Lieferterminen Entwicklungsbudgets sowie
65. mangelhafte Qualit t von Softwareprodukten veranlassten das DoD ein solches Hilfsmittel entwickeln zu lassen Der Fragebogen wurde zu einem Referenzmodell ausgebaut das als Vergleichsnorm f r Softwarelieferanten dienen soll Dieses Referenzmodell erhielt den Namen Capability Maturity Model CMM Die Version 1 0 wurde 1991 ver ffentlicht 1993 kam es auf Grund von R ckmeldungen aus der Industrie zu einer berarbeitung des Modells das zur verbesserten Version 1 1 f hrte 1 1997 1998 forderte das DoD eine berarbeitung bzw Umstrukturierung des Modells welche zur Entwicklung des Capability Maturity Model Integrated CMMI f hrte Dieses Paper soll als eine Einf hrung in das Capability Maturity Model gesehen werden Im Kapitel 2 werde ich mich mit Ursachen und Gr nden f r gef hrdete Projekte befassen da dies der Anlass daf r war warum das SEI mit der Entwicklung des CMM begonnen hatte Um die Qualit t von Softwareprodukten zu garantieren gilt das CMM f r viele Firmen als ein Zertifizierungsstandard Kapitel 3 Im Kapitel 4 werde ich genauer auf die Beschreibung der Reifegrade des Capability Maturity Model eingehen Im Kapitel 5 erfolgt eine kurze Gegen berstellung der CMM Modells mit der neuen Version CMMI Im 6 Kapitel werden Erfahrungen von Organisationen die CMM verwenden kurz skizziert 2 Ursachen und Gr nde f r gef hrdete Projekte Die M glichkeiten der Softwareindustrie pr gen die Visionen vieler Firme
66. ndern haben sich in dem Sektor der Automobilindustrie die Programmiersprachen C und C sehr bew hrt Durch die Projektstandards sollen hier verschiedene Richtlinien vorgegeben werden f r das source code layout den Dokumentationsstil den Sprachgebrauch der Programmierung die Compilerverwendung die Designanwendung Der Vorteil des Standards besteht vor allem darin dem Programm eine bessere Struktur geben zu k nnen und dadurch das Auftreten von Fehler zu verringern 4 2 Pro und Contra Die Entwicklungsprogramme QA C bzw QA CH quality assurance die von MISRA zur Fertigung und Erweiterung vorgeschlagen werden k nnen einen Automatisierungsgrad von bis zu 95 erreichen und erm glichen es unter anderem Software Metriken zu berechnen und auch graphisch darzustellen Das weltweit f hrende Analyse Werkzeug erkennt Implementierungsfehler und Inkonsistenzen im Source Code und bewerkstelligt fr hzeitige Verbesserungen um so sp tere Korrekturen und deren horrende Kosten zu vermeiden Mit Hilfe der zur Verf gung gestellten Richtlinien kann die Code Review Zeit und Testzeit verk rzt Komplexit ten limitiert und der Code Reuse unterst tzt werden um so die Produktivit t und Qualit t zu steigern Bei der Verwendung dieser computerbasierten Modellierungstools ist jedoch besonders auf das Data Dictionary zu achten das f r den korrekten Einsatz unumg nglich ist Um die Effizienz der Verwendung von MISRA QA C C verst n
67. nglich zu machen Diese Probleme betreffen die RS Pro duktion die Endbenutzer unter den unterschied lichsten Umst nden ben tigen Traceability Of what amp In what way information access to and presentation of information depends on an Project characteristics Who wants it Why when they want it user task Abb 5 Probleme des Endbenutzers 1 3 1 2 L sungen bzw L sungsans tze Ein RS wurde produziert um zu spezifizieren was angefordert wird und um Pre Traceability zur Verf gung zu stellen und zu gebrauchen Die Kompliziert heit dieser Anforderungen zeigt an dass es voreilig sein w rde eine komplette L sung anzubieten Es ben tigt ein zusammengesetztes Problem dass zu Verbesserungen dient und in vielen verschiedenen Bereichen einsetzbar ist Anbei die 4 wichtigsten 1 e Zunehmender Fluss an Informationen jeder sollte nur die Informationen erhalten die er auch wirklich ben tigt und nicht generell alle e Erreichen und Notieren von Informationen mit welchen Tools kann ich an die Informatio nen kommen 71 159 e Organisieren und Beibehalten von Informa tionen jeder sollte wissen wer was macht und von wem ich meine eventuell ben tigten Infor mationen bekomme e Zugang und Darstellung der Informationen wenn jemand Zugang zu den Daten ben tigt sollte ihm dieser unter Sicherheitsaspekten ge w hrleistet werden Weiters muss die Darstel lung der Daten vereinheitl
68. r jene die diese Veranstaltungsform bernehmen und weiterentwickeln wollen stichpunktartig zusammen fassen e Freie Themenwahl Sie wurde im Rahmen des Feedbacks von den Studierenden mehrfach als Posi tivum erw hnt Aus Sicht des Lehrveranstaltungs leiters muss jedoch erg nzt werden dass damit auch Risken verbunden sind Einige Extended Abstracts standen unter begr ndetem Verdacht dass die geplante Arbeit sehr plagiatsverd chtig sein w rde Eine Person wurde sogar von der weiteren Teilnahme ausgeschlossen weil bereits das Extended Abstract eine Plagiats Collage war Wie weit diese seminar ffentliche Plagiatsbehandlung dazu f hrte dass einige Studierende nach der Review phase der Extended Abstracts das Seminar verlie en und wie weit Kritik am jeweiligen Extended Abstract oder der offenkundige Zwang kontinuierlich an der Lehrveranstaltung zu arbeiten dazu f hrte kann und soll nicht weiter analysiert werden e Striktes Terminmanagement Dieses war zwar viel leicht f r einige Studierende un blich Es wurde je 147 159 doch sei es der Sache wegen sei es aus Einsicht ber die zu betreuende Studierendenzahl akzeptiert sogar punktuell gelobt Vertraulichkeit Der Gutachtensprozess war als blinder Review organisiert und die Studierenden wur den darauf aufmerksam gemacht dass sie bei beson deren Naheverh ltnissen um Tausch der Zuweisung ersuchen sollten Verletzungen dieser Spielregeln wurden nicht aug
69. regelm ige Abgaben und regelm iges Feedback oder Pflicht Zeit exakt einzuhalten und zwei maliges Nennen von klare Vorgaben geh ren in diese Kategorie Ebenso fallen in diese Kategorie wohl zwei Nennungen bez glich des Umfangs der Arbeit die die L ngenbeschr nkung als sinnvoll bezeichnen Drei Antworten bemerkten positiv gelernt zu haben mit Papers informatischen Inhalts zu arbeiten verfassen auffinden Die restlichen postitiven Antworten betra fen das Arbeitsklima und Aspekte die wohl in jedem Seminar gegeben sein sollten Die Antworten zu NICHT gefallen hat mir waren breiter gestreut hatten jedoch mit 6 Nennungen von fr her Beginnzeitpunkt einen deutlich herausragenden Modus Dieser ist gefolgt von drei Nennungen von zu viele Pr senztermine und zwei Nennungen von geheimer Reviewprozess mit Zusatz namentlich w re objektiver bzw besser wenn jeder weis von wem Reviews stammen Eine Person meinte die Zeit f r die Begutachtung der Langfassungen w re zu knapp bemessen gewesen In diese Kategorie geh rt wohl auch zu viele Reviews pro Person lieber 2 mit mehr Zeit Die Antwort teilweise unklare Aufgabenstellungen Fragen bei Reviews geht wohl auf die Verwendung von Originalformularen zu r ck die wie erw hnt an einigen Stellen nicht ganz f r die studentischer Themenbearbeitungen passten Einen anderen Komplex ber hren Antworten wie Mi schung Bakkalaureatsseminar mit Normalseminar zwei Nennungen oder gro
70. ruft eine Methode m eine Methode f der selben Klasse auf Eine Klasse erbt nun diese Methoden und berschreibt fO Der Aufruf von m f hrt dazu dass die Methode fO in der Subklasse aufgerufen wird was ungewollt zu Fehlern f hren kann Zur berpr fung dessen wird die Methode der Superklasse umbenannt 6 IOR Mutant Class List A void m O Original Code Class List void m f0 void f A void fO class Stack extends class Stack extends List List void f void f 3 Figure 2 lIOR 6 ISK super keyword deletion Dieser Operator entfernt den Aufruf von berschriebenen Methoden bzw versteckten Variablen mittels super Die Referenz wird folglich aus der Subklasse entfernt und dadurch sichergestellt dass Methoden und Variablen zweckm ig verwendet werden 6 IPC Explicit call of a parent s consturctor deletion Bei der Erzeugung eines Objektes einer Subklasse wird automatisch der argumentlose Default Konstruktor der Superklasse ausgef hrt Das kann durch den Aufruf eines speziellen Konstruktors der Superklasse mittels super umgangen werden Diese Anweisungen werden entfernt 6 Polymorphismus Polymorphismus bietet eine sehr gro e Flexibilit t die jedoch mit gro er Verantwortung einhergeht da der Programmierer wissen sollte welche Auspr gung eine Gr e zur Laufzeit haben kann 7 Die korrekte Anwendung dieses objek
71. schon sehr fr h mit der Implementierung beginnen k nnten von Tools die auf Basis des Source Code Metriken zur Verf gung stellen sehr profitieren Einige der OO Metriken lie en sich auch auf das Design anwenden es w ren nur andere Tools zu deren Berechnung notwendig Gute Verwertungsm glichkeiten f r Metriken scheinen mir auch als Hilfsmittel f r Reviews gegeben Hier k nnten schnell Methoden und Klassen ausfindig gemacht werden deren Metriken auff llig abweichen zB hohe WMC einer Klasse Im Rahmen eines Reviews lie e sich der Ursache f r die Auff lligkeit auf den Grund gehen und diskutieren ob eine nderung notwendig ist So lange man OO Metriken rein als Unterst tzung f r den individuellen Entwickler oder f r ein Entwicklerteam betrachtet ist auch das Risiko der von DeMarco beschriebenen Dysfunktion sehr gering Wohl berlegt sollte eine Weitergabe von Messdaten an das Management sein Sollte es auf Software Metriken bestehen empfehle ich den Daten DeMarcos Artikel 5 beizuf gen 65 159 Literatur 1 McCabe Thomas J Butler Charles W Design Complexity Measurement and Testing Communications of the ACM 32 12 December 1989 Chidamber Kemerer A Metrics Suite for Object Oriented Design IEEE Transactions on Software Engineering 20 1994 476 493 N w Etzkorn Gholston Fortune Stein Utley Farrington Cox A comparison of cohesion metrics for object oriented syste
72. sich die Frage wer daf r die Verantwortung tr gt ist es der K ufer der nicht genau formuliert hat was er will oder ist es vielleicht der Verk ufer der nicht genau nachgefragt hat Oder haben hier beide eine Teilschuld Ist der Verk ufer jetzt verpflichtet Anpassungen an die wirklichen Anforderungen ohne Aufpreis durchzuf hren oder sind diese nderungen vom K ufer zu bezahlen Um hier lange Rechtsstrei tigkeiten bez glich Schuld zu vermeiden ist es not wendig die Verantwortlichkeiten im Vorhinein klarzu stellen worauf auch in 11 und 10 ausdr cklich hingewiesen wird Aber auch wenn die Abnahmekriterien genau ge w hlt wurden kann unter Umst nden ihre Pr fung problematisch werden zB Die Suche nach einem Kunden in der Datenbank soll unabh ngig vom Such kriterium nicht l nger als f nf Sekunden dauern Ein diesbez glicher Abnahmetest m sste eigentlich alle Kombinationen aller m glichen Suchkriterien zum Zugriff auf die Kundendatenbank bilden und die jewei ligen Zugriffszeiten testen Bei 10 Suchkriterien w ren das bereits 1023 m gliche Kombinationen Da man dies unter Einhaltung eines vertretbaren Zeitaufwandes nur durch ein Programm testen kann werden bei sol chen Kriterien entweder nur Stichprobentests durchge f hrt oder es wird eine l ngere Testperiode vereinbart in der bereits mit dem Programm gearbeitet wird und hofft dabei dass sich Ausrei er in den kritischen Bedingungen innerhalb dieser Phase
73. sie die Kontrolle ber die Situation haben Entsprechend dem Slogan What you see is what you get sollte der Output von Interaktionen mit dem System immer im Zusammenhang mit dem aktuellen Inhalt des Bildschirms stehen Ein Programm sollte sich flexibel auf die W nsche des Benutzers einstellen und es sollte stets direkte R ckmeldungen nach einem Input geben um dem Benutzer den Erfolg seiner Aktion anzuzeigen Des Weiteren sollte ein Programm jegliche technische Details vor dem Benutzer verbergen und ihn m glichst vor unangenehmen Konsequenzen sch tzen 7 Es lie en sich unz hlige weitere Richtlinien und Standards finden hier sei auf die internationalen Normen verwiesen Um auf die unterschiedlichen Erfahrungsstufen und pers nlichen Pr ferenzen der einzelnen Benutzer eines Programms einzugehen ist Customizing ein hilfreicher Weg Wenn Benutzer in der Lage sind das Programm nach ihren W nschen zu gestalten steigen sowohl Akzeptanz als auch Effizienz Es kann Benutzern freigestellt werden welche Art sie bevorzugen das System mit Input zu versorgen sei es per Maus Keyboard Touchpad oder auf anderen Wegen Weiters k nnen Benutzer in den heute gebr uchlichen Desktops Objekte nach ihren Bed rfnissen anordnen Fensterpositionen und deren Gr e ndern und Farben und Hintergrundbilder w hlen Es sollte m glich sein zwischen verschiedenen Intensit ten der Interaktion zu wechseln je nachdem wie vertraut ein Benutzer mit
74. soll im Jahr 2010 zirka 13 Prozent oder durchschnittlich 1 450 Euro des Fahrzeug Gesamtwertes umfassen Laut Prognose wird sich der Markt f r Software im Vergleich zum Jahr 2000 auf rund 100 Millionen Euro vervierfachen 9 Bezeichnend daf r ist bereits die jetzige Anzahl der eingebauten elektronischen Steuerger te in den neu angefertigten Mittelklassewagen dieser Anteil betr gt inzwischen 20 bis 65 St ck verschiedener Software Komponenten Durch diesen immer gr er werdenden Anteil ist die Software zu einem wettbewerbsentscheidenden Faktor zur Steigerung des Marktimages geworden und erfordert intensive Zusammenarbeit von Forschungspartnern aus der Automobil und Softwareindustrie Der Kunde will ein Massenprodukt das billig und dennoch zuverl ssig ist und eine lange Lebensdauer hat Sofort eintreffende Verkehrsmeldungen und die M glichkeit die Mautgeb hren automatisch bezahlen zu k nnen sind dabei nur kleinere W nsche Die Karosserie selbst unterscheidet sich hierbei bez glich ihrer Haltbarkeit gewaltig von der eingebetteten Software So ist der Lebenszyklus eines KFZs und dessen mechanischen Bauteilen von einigen Services gelegentlichen Erneuerungen von Verschlei teilen und eventuellen optischen Verbesserungen gepr gt Die Software hingegen durchl uft ganz andere Phasen Allein die Best ndigkeit ist eingeschr nkter und die n tigen Updates und Upgrades sind meist unm glich durchzuf hren da
75. sondern unterst tzt sie 6 Literaturverzeichnis Thal01 THALLER Georg Erwin ISO 9001 2000 Software Entwicklung in der Praxis Verlag Heinz Heise Hannover 2001 Funk00 FUNKE Thomas Softwareentwicklung in mittelst ndische Unternehmen mit ISO 9000 Springer Verlag Berlin 2000 Brau02 BRAUER J rg Peter DIN EN ISO 9000 2000ff umsetzen Carl Hanser Verlag M nchen Wien 2002 Balz98 BALZERT Helmut Lehrbuch der Software Technik Spektrum Akademischer Verlag GmbH Hei delberg Berlin 1998 Thal96 THALLER Georg Erwin ISO 9001 Soft ware Entwicklung in der Praxis Verlag Heinz Heise Hannover 1996 Glaa93 GLAAP Winfried ISO 9000 leicht gemacht Carl Hanser Verlag M nchen Wien 1993 Sch 01 SCH BEL Sven Die Revision der DIN ISO 9000 1994 zur DIN ISO 9000 2000 im Vermessungs wesen Diplomarbeit Hochschule f r Technik und Wirtschaft Dresden FH Dresden 2001 Schn97 SCHNEIDER Dieter Modernes Qualit ts management durch ISO 9000 Diplomarbeit Universit t Klagenfurt 1997 IS0094 NORM EN ISO 9000 1 Qualit tsmana gementsysteme Leitfaden zur Auswahl und Anwendung ON sterreichisches Institut f r Nor mung Wien 1994 ISO194 NORM EN ISO 9001 Qualit tsmanage mentsystem Anforderungen ON sterreichisches Institut f r Normung Wien 1994 ISO494 NORM EN ISO 9004 1 Qualit tsmana gement und Elemente eines Qualitatssicherungssystems ON sterreichisches Insti
76. tssicherungsprozess aktiv beteiligt waren kaum Gelegenheit Extended Abstracts zu lesen Deshalb m chte ich hier kurz auf die Unterschiede zwischen beiden Textsorten eingehen und Ihnen so den n chsten Schritt im Seminar etwas erleichtern Funktion des Abstracts Es soll potentielle Leser zu motivieren doch die ganze Arbeit zu lesen Daher der Inhalt warum ist was ich schreibe wichtig was erf hrst Du genauer wenn Du alles liest Wichtig und manchmal schwierig Ein Abstract ist etwas anderes als ein Summary Zusammenfassung oder eine Conclusion Schlussfolgerung Der Inhalt dieser beiden Komponenten eines Aufsatzes geht wohl aus dem Begriff eindeutig hervor und unterscheidet sich von obigem Aus Lekt re von Abstract und Schlussfolgerung oder Abstract und Zusammenfassung sollten Leser ein gutes Bild von dem gewinnen was sie vom Rest der Arbeit erwarten d rfen Leider haben wir im Deutschen f r Abstract und Summary nur die gemeinsame bersetzung Zusammenfassung was verwirrend ist Extended Abstracts Extended Abstracts sind Zwischenprodukte im wissenschaftlichen Produktionsprozess und dienen der Vorselektion von Aufs tzen Workshops Tutorials Panel Discussions etc Daher sehen wir sie als Konsumenten des Endprodukts eher nicht mehr und haben etwas weniger Erfahrung damit Jedenfalls sollte das Extended Abstract auch die Inhalte des eigentlichen Abstracts also warum ist was ich schreibe wichtig was
77. und den Ressourcen Mitarbeitern die zur Verf gung stehen aus Hat man nun also 3 Monate bis zur Fertigstellung des Auftrages Zeit und verf gt man ber 6 Mitarbeiter so braucht man nach diesem Gesetz 18 Personenmonate In man chen F llen hat sich diese Sch tzung als sehr genau erwiesen in anderen wiederum als stark abweichend Diese Methode wird nicht empfohlen 1 2 5 Price To Win Hier werden die Projektkosten durch die beim Auftraggeber verf gbaren Mittel be stimmt Der zu erwartende Aufwand wird durch das Budget des Auftraggebers und nicht durch das Projekt 50 159 selbst bestimmt Hier kommt es oft zu berschreitun gen des Zeitplans und des Budgets was wiederum zu Unzufriedenheit f hrt Price To Win hat eine Vielzahl von Ausschreibun gen f r viele Softwareunternehmen gewonnen Aller dings sind viele davon verst ndlicherweise heute nicht mehr am Markt 1 2 6 Top Down Bei der Top Down Methode wird zuerst der Gesamtaufwand f r ein Projekt gesch tzt und dann wird dieser f r die einzelnen Komponenten heruntergebrochen Dieses Verfahren kann in Kombi nation mit jeder anderen bisher genannten Methode erfolgen Vorteilhaft hierbei ist dass das Projekt als eine Einheit gesehen wird und nicht auf Kosten f r Systemintegration Benutzerhandbuch etc vergessen wird Der Nachteil ist allerdings dass auf Schwierig keiten in Einzelf llen oft nicht im Vorhinein als solche erkannt werden 1 2 7 Bottom Up Die B
78. und dr ckt aus mit wievielen anderen Klassen diese Klasse in einer Kopplungsbeziehung steht Die Kopplungsbeziehung der CBO Metrik ist symmetrisch Hohe Kopplung ist ein Indiz f r schlechtes Design Die Klasse wird durch zuviele Abh ngigkeiten untauglich f r Reuse in anderen Applikationen Abh ngigkeiten zwischen Klassen sollten m glichst minimiert werden um Flexibilit t zu erhalten und so lokale nderungen in einzelnen Klassen erm glichen die nicht auch gleich nderungen in anderen Klassen nach sich ziehen Ein hoher Kopplungsgrad wei t auch auf hohe Komplexit t hin Dementsprechend steigen Fehleranf lligkeit und Testaufwand 3 4 2 Martins OO Design Quality Metric Robert Martin betrachtet zwischen Klassen etwas anders Abh ngigkeiten Er versucht zwischen verschiedenen Arten der Kopplung zu differenzieren und entwickelte daher eine Metrik die gute oder zumindest nicht sch dliche und schlechte Kopplung unterscheidet Die zwischen Klassen notwendige Kommunikation f hrt praktisch unvermeidlich zu einem gewissen Ma an Kopplung Martin f hrt des Fehlen von schlechter Kopplung auf gutes Design zur ck Seine OO Design Quality Metriken sollen auf m gliche Designprobleme die sich in den Abh ngigkeiten der Klassen zeigen hinweisen 0 4 Abh ngigkeiten sind dann ein Problem wenn sie auf Klassen verweisen die instabil sind Instabilit t bedeutet da die Wahrscheinlichkeit da an der Klas
79. verbessern wurden Methoden entwickelt die den Inspektionsteilnehmern den Umgang mit Dokumenten erleichtern und den Fehlerfindungsprozess unterst tzen Visek 2003 Dieses Kapitel besch ftigt sich mit einem Ansatz zur Fehlersuche den Lesetechniken die den Inspektor bei der Arbeit unterst tzen Diese Dokumente und Fragenkataloge werden den Inspektoren in der Einf hrungsphase zusammen mit den anderen Dokumenten vom Moderator bergeben Die einfachste aller Lesetechniken ist die ad hoc Methode welche die erste aller Untersuchungs methoden war und dank Fagan schnell verbreitet wurde Darunter versteht man ein lineares Abarbeiten bzw Lesen des jeweiligen Dokumentes Diese Technik kann in einer Firma ohne grosse Anpassungen und Voraussetzungen eingesetzt werden da ohne bestimmte Leseanleitung einfach nach Fehlern gesucht wird Das ad hoc Verfahren kann zwar auf jedes Dokument angewendet werden kann aber aufgrund der unterschiedlichen Zug nge der Inspektoren und der fehlenden Anleitungen gegebenenfalls nicht gleichartig wiederholt werden Sie wird zwar in der Praxis immer weniger eingesetzt liefert aber Vergleichswerte bei der Untersuchung der Effektivit t und Effizienz verschiedener Lesetechniken Werden Checklisten basierte Lesetechniken angewandt so wird eine Liste bestehend aus einer Reihe von Fragen die sich einerseits auf allgemein g ltige Dinge wie etwa Vollst ndigkeit Konsistenz oder Layout und andererseits auf spe
80. versuchen das Objekt Produkt Prozess Ressource hinsichtlich der selektierten Quali t tsanforderungen zu definieren Dabei ist zu beachten dass die Definition den gew hlten Gesichtspunkt bzw die gew hlte Thematik ber cksichtigt Quantitative Ebene Metric Konkret gemessene Werte werden den Fragen der jeweiligen Ziele zugeordnet um eine quantitative Antwort zu liefern Eine Metrik kann hier f r mehrere Fragen relevant sein Die gemessenen Werte sind e Objektiv Wenn sie nur von dem quantitativ zu erfassenden Objekt abh ngen und nicht von der Sichtweise aus der sie betrachtet wer den z B Anzahl der Versionen eines Doku ments Arbeitsstunden f r eine gewisse Auf gabe Gr e des Programms e Subjektiv Wenn sie sowohl von dem Objekt als auch der Sichtweise abh ngen z B Les barkeit von Text Grad der Kundenzufrieden heit 2 2 Phasen der GQM Methode Die GQM Methode wird in 4 Phasen aufgeteilt siehe Abbildung 2 Question Mf Antwort Metric f gt Messung Projektplan Definition Interpretation Y Y gt Gesammelte Werte Planung Datensammlung Abbildung 2 4 Phasen der GQM Methode 6 Planungsphase In dieser Phase sollen die Voraussetzungen f r die erfolgreiche Durchf hrung eines GQM Messpro gramms geschaffen werden Hierzu z hlt neben der Motivation und Ausbildung der Mitarbeiter die Ers
81. von einzelnen Komponenten sein k nnte Je gr er die Kop plung desto ausf hrlicher muss getestet werden 3 5 Response for a Class RFC DEFINITION 5 RFC RS wobei das RS Response Set einer Klasse die Menge aller lokalen Methoden und die durch lokale Methoden der Klasse gerufenen Methoden ist Diese Metrik ist somit die Anzahl aller verschiedenen Me thoden die in der untersuchten Klasse aufgerufen werden zuz glich der Methoden welche die Klasse selbst besitzt RFC zeigt somit die theoretisch m gliche Anzahl an Me thoden an die durch Senden einer Nachricht an ein Ob jekt ausgel st werden k nnen Je gr er die Anzahl ist desto komplexer ist die Klasse programmiert Weiters wird durch einen hohen RFC Wert vor allem das Testen der Me thoden und das Finden von Fehlern in den Programmen entsprechend aufwendiger da vom Tester ein gr eres Ver st ndnis ben tigt wird 3 6 Lack of Cohesion in Methods LCOM DEFINITION 6 Sei C eine Klasse mit n Methoden M M2 Mn Sei Ij die Menge aller Instanzvariablen die von der Methode M genutzt wird Dann gibt es n solche Mengen Ih In Sei P L L NI 0 und Q 1 17 ENI 0 Wenn allen Mengen hh In sind dann sei P wenn P gt Q sonst zcom eee Um den Mangel an Koh sion in einer Klasse zu messen sortiert man die Methoden einer Klasse nach dem Satz von Variablen die sie benutzen oder ver ndern LCOM ist
82. von der Genauigkeit der verwendeten Klassen Analyse abh ngt Klassen Analysen sind eine Form der statischen Programmanalyse und wurden urspr nglich f r optimierende Compiler verwendet Eine Klassen Analyse liefert f r jede Variable x eines Programms die Menge der Klassen KM x welche zur Laufzeit m glicherweise an diese Variable gebunden werden Die Klassen Mengen sind je nach Analyse Methode verschieden pr zise Der Algorithmus in Abbildung 5 ben tigt als Eingabe alle Statements und Methoden eines Programms sowie die Ergebnisse der Klassen Analyse des selben Programms Das Resultat des Algorithmus ist ein ORD welcher je nach Pr zisiongrad der vorhergehenden Klassenanalyse in der Genauigkeit variiert Der damit gewonnene ORD unterscheidet sich nur in den Assoziations Beziehungen vom ORD des naiven Ansatzes EINGABE Statements Menge von Statements Methoden Menge von Methoden KM Ausgabe der Klassenanalyse AUSGABE ORD Vererbungsbeziehung F r jede direkte Subklasse S der Klasse K ORD ORD U I S K Aggregationsbeziehung F r jedes Statement s der Form this var new K in einem Konstruktor der Klasse A ORD ORD U Ag A K Variablen Zugriffs Assoziationsbeziehung Fur jedes Statement s der Form obj var in der Klasse A Wenn ofthis ORD ORD u As A KM obj Methoden Aufruf Assoziationsbeziehung F r jeden Methodenaufruf obj m in der Klasse A Wenn ofthis ORD ORD u As A KM obj
83. war bei den Bakkalaureatsstudierenden die Pro seminar Erfahrung mit 4 6 deutlich h her als bei den Seminaristen 3 4 Seminaristen hatten jedoch im Vorf eld im Schnitt bereits 2 4 Seminare besucht w hrend Bakkalaureatsstudierende lediglich 1 4 Seminare vorab 148 159 absolvierten Damit wurde die Vermutung der Lehrver anstaltungsleitung dass Seminaristen bereits ber h here Seminarerfahrung verf gten als die Bakkalaureatsstudie renden und daher insbesondere in der Anfangsphase der Lehrveranstaltung weniger leichter Tritt fassten ein wenig best tigt Dieser Befund sollte wohl in k nftigen Bakkalaureatsseminaren besondere Ber cksichtigung finden Die Antworten bez glich Aufwand und relativer Er trag der Lehrveranstaltung sind in der nachfolgenden Tabelle dargestellt Hiezu ist zu bemerken dass die Gesamtzahl der Antworten stets um 1 gr er ist als die Summe der Antworten der Bakkalaureats und Seminar Studierenden da eine Person dieses Zuordnungsfeld nicht ausf llte und daher nur in der Gesamtsumme aufscheint stud Aufwand Bakk Semi vs Ertrag Stud naristen gesamt Ertrag relativ zu anderen seminaristischen LVs etwa gleich 2 2 4 mehr 5 6 12 Ertrag relativ zu durchschnittlicher LV weniger 1 1 etwa gleich 4 6 10 mehr 1 2 4 viel mehr 1 1 Aufwand relativ zu anderen seminaristischen LVs gleich 1 3 4 h her 4 4 9 viel h her 2 1 3 Aufwand relativ zu durchschnittlicher LV weniger 1 1 gleich
84. werden und das Lernen per Dokumentation aufgrund der Komplexit t zu ineffizient w re 5 Fazit Es ist in jedem Entwicklungsprozess einer Benutzerschnittstelle zu empfehlen s mtliche M glichkeiten zu nutzen ein neues Produkt so zu entwickeln dass es von den Benutzern sp ter akzeptiert wird Hier sind Faktoren wie kulturelle Pr gung und bisherige Erfahrung sowie kognitive F higkeiten zu ber cksichtigen Die M glichkeiten hier eine hohe Akzeptanz zu erlangen sind keine Wundermittel aber ihre Einhaltung erleichtert die sp tere Abnahme des Produkts Spezieller Augenmerk ist auf Methoden zu legen die vor oder w hrend der Entwicklung eingesetzt werden k nnen sie stellen 84 159 sicher keine berm ige Ressourcenbelastung dar und haben eine deutliche Wirkung 6 Literatur 1 http www isys uni klu ac at IS YS Courses 03S S eva vounterlagen 9 10 2 OGestaltung 20von 20Benutzungsschnittstellen 2 Stefan Leuthold Benutzer sind vom Mars Entwickler von der Venus http www stimmt ch knowledge 20030304 benutzerv ommars pdf 2003 3 Joerg Kampmann http homepage ruhr uni bochum de Joerg Kampmann HTML ScreenDesign ht m 4 Ernst Denert Software Engineering Springer Verlag Heidelberg 1991 5 D C Gause G M Weinberg Software Requirements Anforderungen erkennen verstehen und erf llen Hanser Verlag M nchen Wien 1993 6 Don Yeates Maura Shields David
85. zu bedenken also Ereignisse die auf keinen Fall eintreten d rfen Generell sollen Erwartungen klar ausgedr ckt werden da Fehler bei ihrer Erfassung zu Ungunsten der Benutzer und damit zu Ungunsten des Projekts gehen Dar ber hinaus ist es sinnvoll bewusst Erwartungen die nicht erf llt werden k nnen auszuschlie en Einerseits um die Grenzen des Produkts zu kl ren und ihm damit eine klarere Identit t zu geben andererseits um Entt uschungen die auf unausgesprochenen Erwartungen beruhen vorzubeugen Weinberg 5 spricht von einem Prozess bestehend aus vier Schritten Zuerst werden m glichst repr sentative Benutzer nach ihren Erwartungen gefragt daraus wird dann eine Liste erstellt Diese Liste wird dann generalisiert und zuletzt werden die generalisierten Listeneintr ge drei Gruppen zugeordnet m glich verschieben unm glich Die Elemente der ersten Gruppe werden umgesetzt die der zweiten kommen auf eine Warteliste und die der dritten werden verworfen Um die Erwartungen der Benutzer richtig zu erfassen ist die Kultur der Kommunikation von gro er Bedeutung Hierzu ist es nicht nur wichtig mitzuteilen sondern auch sicherzugehen dass die Nachricht empfangen und verstanden wurde Feedback ist von gro er Bedeutung und wer kein Feedback von den Benutzern einholt kann niemals Gewissheit haben wo er gerade steht Unterscheiden kann man Kommunikation in schriftlich bzw m ndlich und formell bzw informell was davon zur
86. 1 3 5 4 5 h her 4 3 5 8 5 viel h her 2 2 Nutzen gelohnt 4 5 10 ann hernd o k 3 2 5 nicht gelohnt no response 3 Dabei wurden die ersten vier Fragen auf einer f nfteiligen Skala viel weniger weniger etwa gleich Im Bakkalaureatsstudium Informatik ist dieses Bakkalau reatsseminar das einzige Pflichtseminar Die Vorerfahrung stammt daher aus anderen Fachgebieten Anwendungsfach oder aus Studienpl nen nach denen vor einem allf lligen Wechsel in das Bakkalaureatsstudium studiert wurde mehr viel mehr der Nutzen auf einer dreiteiligen siche rlich gelohnt war ann hernd o k nicht gelohnt abge fragt Unter den frei formulierten Antworten zu gefallen hat mir stechen 9 Nennungen der Art viel Feedback zu den Arbeiten hervor Diese sind noch durch 2 Nennungen von Reviews 2 Nennungen zu Analyse der Pr sentation und 3 Nennungen Kommentare des LV Leiters zu erg nzen Letzteres wird allerdings durch 2 Nennungen des LV Leiter Feedbacks unter nicht gefallen relativiert Eine wietere reviewbezogene Antwort lautete Review anderer Arbeiten Damit kann der gekoppelte Begutachtungspro zess durch Kommilitonen wie Lehrveranstaltungsleitung als deutlich positiv beurteilt angesehen werden Weitere Mehrfachnennungen betrafen die Veranstal tungsform einer Konferenz dreimal und die freie Themenwahl zweimal am Fragebogen genannt in der Abschlussdiskussion jedoch deutlich unterstrichen Auch Antworten wie
87. 10 0 88 0 81 n a PEXP 1 19 1 09 0 91 0 85 n a LTEX 1 20 1 09 0 91 0 84 TOOL 1 17 1 09 0 90 0 78 n a SITE 1 22 1 09 0 93 0 86 0 80 e me e e lo SCED 1 43 1 14 1 1 n a Bei der Gr e des Projektes werden zus tzlich zwei wichtige Einfl sse ber cksichtigt SOMMO1 Die Unbest ndigkeit der Anforderungen Man geht davon aus dass eventuell noch Nachar beiten aufgrund von nderungen der Systeman forderung zu leisten sind Diese sollen in ihrem 55 41650 Zeilenausma gesch tzt werden und zu der nor malen Gr ensch tzung hinzuaddiert werden Der Umfang einer m glichen Wiederverwendung Bei einem umfangreichen Reuse muss die Zeilen anzahl des tats chlich entwickelten Quellcodes ver ndert werden Nun ist es jedoch so dass die Kosten f r eine Wiederverwendung aufgrund des ben tigten Aufwandes zur Findung und Auswahl der Komponenten und deren Schnittstellen sowie den notwendigen nderungen nicht linear verlau fen Dies findet in COCOMO I Ber cksichtigung Der Gr enaufwand wird durch nachstehende Formel angen hert ESLOC ASLOC AA SU 0 4DM 0 3CM 0 3IM 100 Abbildung 6 Formel f r Reuse ESLOC extension source lines of code steht f r die Zeilenanzahl des neuen Codes ASLOC adapted source lines of code f r die nderungsbed rftige Zei lenanzahl des wiederverwendbaren Codes
88. 2 February 2000 6 H Balzert Lehrbuch der Software Technik Software Management Software Qualit tssicherung Unternehmens modellierung Berlin 1998 7 J M Voas Certifying Off the Shelf Software Compo nents Computer Vol 31 No 6 1998 131 159 Effektives Testen Objektorientierter Software mit Objekt Relations Diagrammen Stefan Perauer Robert Sorschag 0061102 0060423 sperauer rsorschl edu uni klu ac at Abstract In objektorientierten Systemen ist ein hoher Grad an Interaktion zwischen den Klassen vorhanden wodurch das Testen erschwert wird Ein gro es Problem von Integrations und Regressions Testen ist es eine effektive Testreihenfolge zu finden die den n tigen Aufwand zum Testen minimiert In dieser Arbeit werden Objekt Relations Diagramme ORDs vorgestellt mit deren Hilfe dieses Problem gel st werden kann Neben einer ausf hrlichen Beschreibung der Probleme des objektorientierten Softwaretests wird ein Algorithmus zur Konstruktion beliebig pr ziser ORDs angef hrt Pr zisionsunterschiede ergeben sich durch verschiedene Ans tze f r ORDs die entwickelt wurden Weiters wird gezeigt wie ORDs beim Integrations und Regressions Testen zum Einsatz kommen 1 Einleitung Objektorientierte Software besitzt einige grundlegende Unterschiede im Vergleich zu prozeduraler Software Durch die Einf hrung neuer Konzepte wie Vererbung Aggregation und Assoziation entstehen komplexe Abh ngig
89. 4 1 1 Bidirektionales Traceability Das bidirektionale Tracing schlie t beide Richtun gen ein jenes nach vor und auch das zur ck Das Vor w rts Tracing wird zur Verf gung gestellt wenn jede Anforderung einen eindeutigen Designbestandteil referenziert In anderen Worten gesagt l sst Vorw rts Traceability einen wirklich sehen wo Anforderungen im Endsystem verwirklicht werden Das R ckw rts Tracing wird hingegen dann zur Verf gung gestellt wenn jede Anforderung von einem eindeutigen Designbestandteil referenziert wird 72 159 4 1 2 Kritik von Anforderungen Ein sinnvoller Weg kritische Anforderungen zu i dentifizieren ist es wenn jene mit den zentralen Auf tr gen des Systems in Beziehung gestellt werden Ge sch ftsprozesse oder Auftr ge die Anforderungen erzeugen k nnten gekennzeichnet und Anforderungen im Bezug auf solche Prozesse ausgewertet werden um eine Klassifikation zu erm glichen Zum Beispiel sollte Traceability Punkte aufzeichnen wie Anforde rungen eingelangt sind 4 1 3 Grundprinzip des Designs Eine grundlegende Komponente des Traceability ist ihr Design Traceability Verbindungen um jene Grundprinzipien zu repr sentieren w rden das Wa rum bzw den Grund von Designentscheidungen er l utern Das Nachverfolgen entlang eines Designobjek tes und das Verstehen wie sich eine nderung auf welches Objekt auswirkt ist lebensnotwenig bei der Wartung des Systems 4 1 4 Projektverfolgu
90. 7 345 5 A Snyder Encapsulation and Inheritance in Object Oriented Programming Languages SIGPlan Notices November 1986 pp 38 45 6 Y Ma Y Kwon J Offutt Inter Class Mutation Operators for Java 13 International Symposium on Software Reliability Engineering Annapolis MD November 2002 7 H Gall M Hauswirth R Kl sch Object oriented concepts in Smalltalk C Objective C Eiffel and Modula 3 Technical University of Vienna 1995 8 J Gosling et al The Java Language Specification Second Edition 1996 9 S Kim J Clark J McDermid Class Mutation Mutation Testing for Object Oriented Programs In Object Oriented Software Systems Net ObjectDays 2000 Germany October 2000 10 J Offutt J Pan Automatically Detecting Equivalent Mutants and Infeasible Paths In The Journal of Software Testing Verification and Reliability September 1997 Vol 7 No 3 pp 165 192 11 Y Ma Y Kwon J Offutt MuJava An Automated Class Mutation System 2004 143 159 144 159 Reflexionen zum Bakkalaureatsseminar aus Angewandte Informatik Sommersemester 2004 Roland Mittermeir Institut f r Informatik Systeme Universit t Klagenfurt roland isys uni klu ac at Abstract Das erste Bakkalaureatsseminar aus Angewandte Informatik der Universit t Klagenfurt wurde als Kon ferenzseminar organisiert Dies erlaubte trotz hoher Zahl von Studi
91. Anwendung kommt h ngt von der Absicht des Mitteilenden und von seinem Publikum ab Kommunikationsbarrieren k nnen mangelnde Vorbereitung K rpersprache Akzent oder anderes sein und auf die potenzielle F higkeit des Gegen bers dies auszugleichen sollte man sich nicht verlassen 6 Wird eine Ver nderung an einem System vorgenommen oder ein System gegen ein anderes ausgewechselt ist sowohl mit positiven als auch negativen Reaktionen zu rechnen Bei einfacher Betrachtungsweise gibt es Benutzer die Verbesserungen begr en und solche die lieber bei Bew hrtem bleiben Aber dar ber hinaus gibt es bei jeder Ver nderung immer Gewinner und Verlierer selbst die revolution rste Verbesserung wird auf irgendeinem Gebiet eine Verschlechterung bedeuten 5 Daraus folgt dass es sinnvoll ist alle m glichen aktiven und passiven Benutzergruppen zu betrachten 78 159 und herauszufinden was sie gewinnen und verlieren Weiters mag es sinnvoll sein bewusst festzulegen welche Benutzergruppen Verlierer sein sollen beispielsweise soll Kindern der Umgang mit Steckdosen oder Einbrechern der Zutritt zu einem Geb ude erschwert werden Genauso wie Benutzer Ver nderungen anregen k nnen aber auch Ver nderungen Benutzer hervorbringen wenn beispielsweise ein Labor in einem Krankenhaus schnellere Analyseger te bekommt wird die Zahl der Anfragen ebenfalls steigen Betrachtet man die menschliche Wahrnehmung so ist die Grundlage die Au
92. Auslieferungstermin der Software reicht dann k nnen nur die oben erw hnten Produktivit tssteigerungen von 25 35 erreicht werden Wird aber die Wartungsphase mit ber cksichtigt z B weil die Software von der eigenen IT Abteilung gewartet werden muss dann tragen Inspektionen noch deutlich dar ber hinaus zur Kostenreduktion im eigenen Unternehmen bei Trotz all dieser Vorteile ist zu erw hnen dass Inspektionen das Testen zwar erg nzen aber es niemals ersetzen k nnen Ein erw hnenswerter Nachteil der Inspektion besteht darin dass sie keinen oder nur sehr wenig Aufschluss ber das Laufzeitverhalten und das Zusammenspiel der einzelnen Komponenten einer Software Auskunft gibt Au erdem werden wie schon zuvor erw hnt mit einer Inspektion nicht alle der in einem Softwareprojekt enthaltenen Fehler aufgedeckt die restlichen m ssen dann bevor das Produkt dem Kunden bergeben wird durch gr ndliches Software Testen ausgemerzt werden Das bedeutet zwar m glicherweise einen gro en Arbeits und Zeitaufwand ist aber unumg nglich wenn das Produkt einem hohen Qualit tsstandard entsprechen soll 4 Tool unterst tzte Erfassung Lotus Inspection Data System Eine M glichkeit die Ergebnisse einer Inspektion zu erfassen zu archivieren und zu analysieren stellt das Lotus Inspection Data System dar Dieses frei verf gbare Tool Download hilft die erfassten Ergebnisse einer Inspektion in tabellarische und graphische Form zu b
93. Entwickler sinkt die Zahl an berraschungen die ihnen bevorstehen k nnten und eine schnelle Vertrautheit mit einem neuen Produkt ist um vieles leichter zu erlangen F r den Fall dass die Anzahl der Benutzer eingesch tzt werden kann und diese dem Entwickler in der Anforderungsanalyse zur Verf gung stehen mag dies 81 159 von geringerer Bedeutung sein da ein qualitativ hochwertiger Prozess der Anforderungsanalyse ebenfalls berraschungen vermeiden kann aber wenn es sich um ein Produkt f r den freien Markt handelt das nicht f r einen bestimmten Benutzerkreis vorgesehen ist steht in der Anforderungsanalyse niemand zur Verf gung der W nsche u ern kann und hier ist der Einsatz von Richtlinien und Standards eine Absicherung um einer sp teren Akzeptanz n her zu kommen Beispiele f r Richtlinien sind Kompatibilit t sowohl zu Vorg ngern als auch zu Konkurrenzprodukten und Kompatibilit t zur Art und Weise wie ein Benutzer seine Aufgaben zu bew ltigen versucht Programme sollten konsistent sein was bedeutet dass Designs und Muster sich durch das ganze Programm ziehen und in jeder Maske wieder zu finden sind Es sollten stets vertraute Muster Verwendung finden und eine Benutzerschnittstelle sollte unkompliziert sein selbst wenn das Programm viele Funktionalit ten zur Verf gung stellt Benutzer sollten in der Lage sein so viel wie m glich direkt zu manipulieren und das System sollte ihnen das Gef hl geben dass
94. G Mannheim 1991 SOMMOI I Sommerville Software Engineering Pearson Studium M nchen 2001 TUWI04 0 V Barry W Boehm URL http cartoon iguw tuwien ac at 16080 fit fit0 1 spiral entsteh ung html Wien 2004 UNIM04 0 V Tools URL www unibw muenchen de campus WOW v1052 _private Tools ppt M nchen 2004 57 159 Metriken zur statischen Analyse objektorientierten Source Codes Edmund Urbani 1 Juli 2004 Zusammenfassung Die pr zise Messung von Komplexit t und Qualit t von Software ist ein Ziel das in der Informatik schon lange verfolgt wird und mit der Zeit zu immer neuen Vorschl gen f r entsprechende Metriken f hrte Die dabei entstandenen Software Metriken k nnen ein wertvolles Hilfsmittel im Entwicklungsproze sein Besonders praktisch und g nstig ist es wenn die entsprechenden Metriken auch noch automatisch mit geeigneten Werkzeugen direkt auf Basis vorhandenen Source Codes errechnet werden k nnen Die Zahl der Metriken die hierf r herangezogen werden k nnen ist auf den ersten Blick praktisch un berschaubar Dies betrifft vor allem die traditionellen Metriken der strukturierten Programmierung aber auch die Zahl der OO Metriken ist stark im Steigen Diese Arbeit soll einen Einstieg in den Bereich der Metriken bieten Zun chst werden die wichtigsten Klassiker unter den Metriken vorgestellt und auf ihre Anwendbarkeit auf heutige objektorientierte Software hinterfragt Der Schwe
95. H erzeugt Die darin enthalten Kanten werden wieder gewichtet und eine Maximalwert Kante in diesem Fall As A B wird gel scht Im Folgenden werden noch SCC und SCC erzeugt wobei die Kanten As E F und As C H gel scht werden In Abbildung 8 sind alle Schritte dargestellt Die verbleibende SCC enth lt nach dem L schen der As C H keine Zyklen mehr und der Algorithmus terminiert Abb 8 SCCs und gel schte Kanten des ORDs 4 2 Integrations Testen Das Ziel des Integrations Testen ist Fehler aufzudecken die durch Klasseninteraktionen zustande kommen Dabei ist immer eine Zielmenge von Klassen im Test Alle Klassen die nicht in der Zielmenge liegen m ssen durch Stubs simuliert werden F r die Klassen der Zielmenge muss wiederum eine Testreihenfolge gefunden werden Daf r m ssen vorher alle Zyklen aufgel st werden F r das eben beschriebene Beispiel zeigen wir folgend eine Integrations Testreihenfolge wobei wir annehmen dass alle Klassen in der Zielmenge liegen Da alle Zyklen bereits entfernt wurden kann die Testreihenfolge durch eine topologische Sortierung auf dem azyklischen ORD ermittelt werden 1 A wird mit dem Stub C getestet 2 E wird mit A und dem Stub F getestet 3 C wird mit A E und dem Stub H getestet 4 H wird mit C und dem Stub B getestet 5 D wird mit A und H getestet 6 F wird mit E und D getestet 7 B wird mit C D und H getestet 8 G wird mit F und B getestet 9 I wird mit G getestet 10 J
96. Meinung dass es eine teilweise Verbesserung gab und 14 sprachen von geringem bis keinem Erfolg Unternehmen die ihre Softwareprozesse mit CMM verbessern konnten f hrten folgende Gr nde f r die erfolgreiche Umsetzung an e Das Management berwachte aktiv den Fortschritt der Prozessverbesserung e Es gab klar definierte verst ndliche Ziele der Prozessverbesserung sowie genaue Vorgaben bez glich der Kompetenzzuteilung e Das technische Personal wurde stark in die Prozessverbesserung miteinbezogen e Es gab ausreichend Ressourcen die der Prozessverbesserung zugeteilt wurden Organisationen denen es nicht gelungen ist ihre Prozesse mit CMM zu verbessern nannten folgende Merkmale e Obwohl es den Unternehmen bewusst war welche Ver nderungen sie in ihren Prozessen vorzunehmen haben h tten sie mehr Hilfestellungen daf r ben tigt wie sie die Ma nahmen umsetzen k nnen e Die Softwarefirmen sehen in dem Verbesserungsprozess eine zus tzliche Belastung die sie von der eigentlichen Arbeit abh lt e Sie sind entmutigt durch schlechte Erfahrungen mit zuvor gescheiterten Prozess nderungsversuchen 4 6 Conclusio CMM zeigt auf was eine erfolgreiche Softwareorganisation auszeichnet n mlich die Durchf hrung von nderungen Das bedeutet dass die Organisationen die dem CMM folgen ganz gleich auf welcher Stufe sie sich befinden zumindest eine Gemeinsamkeit haben Sie alle konzentrieren sich auf Prozessverbesser
97. Praktiken ein Teil der Routine und werden effektiv in den Prozess miteinbezogen Die f r den Reifegrad spezifischen Sammlungen von Software und Management Praktiken werden als Schl sselprozessbereiche SPBs bezeichnet Jeder SPB setzt sich aus Schl sselpraktiken zusammen die angeben was zu tun ist um den jeweiligen SPB zu erf llen Es wird jedoch nicht spezifiziert wie genau dies zu tun ist 2 900 159 Optimizing 2 Managed Defined 7 Repeatable 2 Initial Abb Reifegrade eines Prozesses 4 1 Stufe 1 Initial Ein Prozess der Stufe 1 ist ad hoc und wird nur wenig gelenkt Es gibt keine Vorgaben zur Planung und Steuerung von Projekten Der Erfolg oder Misserfolg eines Projektes h ngt in erster Linie von den Bem hungen der Motivation und der Qualifikation der beteiligten Personen ab Auf dieser Stufe arbeitet eine Organisation ohne effektive Kostensch tzung Qualit tssicherung oder Projektplan Ebenso wenig wird auf eine effiziente Zeitabsch tzung der Entwicklung eines Produkts Wert gelegt Weiters existieren keine einheitlichen Richtlinien um den nderungen des Softwareprozess zu berwachen Change control 5 Jedes Projekt einer Organisation der Stufe 1 wird als ein neues Projekt empfunden da auf bereits gemachte Erfahrungen nicht zur ckgegriffen werden kann Der Softwareprozess der Stufe 1 ist recht weit verbreitet 32 2 der Sof
98. Problem werden siehe den Erfahrungsbericht von Johnston Peters Schneider und Wellen 4 In diesem Bericht stellt die Sprachbarriere ein Hindernis dar Ein Konflikt zwischen zwei Teams aus verschiedenen L ndern lie sich erst durch pers nlichen Kontakt beilegen als die Teammitglieder feststellten dass die verschiedenen Termini die sie verwendeten das gleiche bedeuten Ein weiterer potentieller Konfliktpunkt ist der unterschiedliche kulturelle Hintergrund der verschiedenen Projektteams Das Auftreten von Kulturunterschieden wird oft untersch tzt Teams m ssen nicht von verschiedenen Kontinenten stammen um unterschiedliche Kulturen zu repr sentieren Bei einem sterreichisch schweizerischen Projekt kam es zu inkompatiblen Hilfetexten da es in der Schweiz kein B gibt siehe Led 3 Nat rlich steigen die kulturellen Unterschiede mit der Entfernung der L nder aus denen die Projektmitarbeiter kommen Die im jeweiligen Land blichen Umgangsformen und Hierarchien m ssen gewahrt werden Kulturelle Beschr nkungen m ssen allgemein bekannt gemacht werden So ist in streng islamischen L ndern die Gebetszeit zu respektieren Falls es zu Konflikten zwischen den Umgangsformen der einzelnen Kulturen 103 159 kommt muss ein Kompromiss erarbeitet und vor allem auch publik gemacht werden Es ist wichtig dass sich alle beteiligten Kulturen akzeptiert und angenommen f hlen Wenn nicht f hrt das zu Unzufriedenheit die sich
99. Software Qualit t Arbeiten des Bakkalaureatsseminars aus Angewandter Informatik Sommersemester 2004 Seminarleitung Roland T Mittermeir Institut f r Informatik Systeme Universit t Klagenfurt Juli 2004 TR ISYS 04 07 01 Bakkalaureatsarbeiten aus Informatik Seminar aus Angewandter Informatik Sommersemester 2004 Vorwort Dieser Sammelband enth lt die im Rahmen des Seminars aus Angewandter Informatik erstellten Arbeiten Darunter sind acht Bakkalaureatsarbeiten und zehn von elf klassischen Seminararbeiten Die unterschiedliche L nge der einzelnen Beitr ge entspricht den unter schiedlichen Vorgaben f r Arbeiten unterschiedlicher Kategorien F r Bakkalaureatsarbeiten wurden 6 ECTS Punkte vergeben Seminararbeiten die entsprechend der Studienordnung 2002 verfasst wurden werden mit 4 ECTS Punkten gewichtet Details der Abwicklung der Lehrveranstaltungen sowie Reflexionen ber das erste Bakkalaureats Seminar in Angewand ter Informatik sind in einem abschlie enden Beitrag des Lehrveranstaltungsleiters dargelegt S mtliche Arbeiten wurden zum Globalthema Software Oualit t verfasst Die Reihenfolge der Pr sentation richtet sich nach Art der Arbeit Der Band beginnt mit den Bakkalaureatsarbei ten da diese Raum hatten ein selbst gew hltes Thema im Umfang von 10 Proceedings Seiten zu bearbeiten Es folgen die reinen Seminararbeiten Hier hatten Zweierteams einen Raum von sechs Seiten und Einzelautoren vier Seiten zur Ve
100. Sollten die Ar beiten mehr Zeit erfordern muss man n tigenfalls auch Teile seiner Freizeit daf r opfern Weiters ist zu ber cksichtigen dass Arbeiten mit hoher Priorit t so schnell wie m glich bearbeitet wer den sollten 126 159 5 2 Bew hrung der vorgestellten Methoden in Schule und Beruf Als angehende Lehrerinnen die bereits das Schul praktikum absolviert und dadurch Einblick in den Schulalltag aus der Sicht des Unterrichtenden gewon nen haben sind wir der Meinung dass die vor gestellten Methoden von Humphrey durchwegs rele vant f r Sch ler und auch Lehrer sind Allerdings ergeben sich auch einige Schwierig keiten in der Umsetzung die im Weiteren genauer er l utert werden Die Akzeptanz bei den Lehrern Sch lern aber vor allem auch bei den Eltern ist sicherlich ein Faktor der dar ber entscheidet inwieweit Zeitmanagement wirk lich im geheimen Lehrplan Einzug findet Eine Weigerung solche Methoden in den Unterricht aufzunehmen k nnte zum einen ein ungewohnter Zeit aufwand f r die Planung sein Zum anderen besteht auch die Gefahr des gl sernen Sch lers der unfrei willig durch die Kontrolle der pers nlichen Aufzeich nungen des Sch lers entsteht Andererseits bleibt dem Lehrer wenn er diese Methoden einsetzt keine Alternative als die Aufzeich nungen zu kontrollieren da sonst einige Sch ler dazu verleitet w rden gar keine Aufzeichnungen zu machen Die Kontrolle des Lehrer
101. Zusammensetzung des Funktions Integrations System Installations und Leistungstests Die Tests werden im TUVIT TestCenter TTC durchgef hrt Dort werden auch Mitarbeiter ausgebil det Methoden weiterentwickelt und Testtools erprobt Zu den weiteren Dienstleistungen des TTC geh ren auch Workshops und Schulungen zu Testmethoden und Testwerkzeugen sowie die Bereitstellung komplet ter Testteams mit Erf llung der Aufgaben des Test managements Testplanung Testspezifikation und Testdurchf hrung Es gibt keine adhoc Tests da systematisch und strukturiert vorgegangen wird Der Vorteil f r den Kunden liegt hier darin dass die T VIT Erfahrungen und Know How durch die Durch f hrung zahlreicher Testprojekte gesammelt hat Dass T VIT eine hohe praktische Bedeutung hat sieht man meiner Meinung nach auch daran dass andere Unternehmen unter anderem Microsoft Deutschland www microsoft de sowie die bremen online services GmbH amp Co KG www bos bremen de ein Unternehmen das E Goverment L sungen f r die deutsche Regierung realisiert Wert auf T V Zertifizierung legen und das auf ihren Homepages gro herausstreichen W hrend sich die T VIT an den tats chlichen Kunden richtet wendet sich die n chste Firma eher an die Entwickler 6 2 Software Quality Systems AG Eine andere renommierte Firma auf dem Gebiet des Qualit tsmanagements ist die K lner SQS Software Quality Systems AG SQS bietet eine umfassende Auswah
102. a nahmen 2 Qualit tssicherung Qualit tssicherung wird durch eine Eigenschaft ge gen ber anderen T tigkeiten innerhalb eines Software entwicklungsprozesses besonders hervorgehoben st ndige Begleitung der einzelnen Phasen innerhalb des Softwareentwicklungsprozesses Durch diese Eigenschaft wird der Qualit tssicherung eine besondere Bedeutung zugeordnet die zu oft vergessen wird Qualit tssicherung tr gt wesentlich zu dem Er folg eines Softwareentwicklungsprozesses bei Qualit tssicherung umfasst alle Ma nahmen die geeignet sind die geforderte Qualit t eines Software produkts zu erreichen oder zu erhalten Dies geschieht insbesondere hinsichtlich gewisser Qualit tskriterien 23 diese w ren zum Beispiel Korrektheit Zuverl s sigkeit Wartbarkeit Verst ndlichkeit Verwendbarkeit und Dokumentation Diese Kriterien sind ma geblich f r die Art der Qualit tssicherung und den erw hnten Ma nahmen Daher umfassen diese Ma nahmen zum Beispiel die Aufstellung eines Qualit tsplans die Planung von Reviews Inspektionen und Tests und die Durchf hrung dieser Methoden Des Weiteren wird auch die Festlegung auf Richtlinien und Standards sowie die begleitende Dokumentation darunter verstanden Dieser kurze berblick soll belegen dass Qualit tssicherung ein wesentlicher Teil des Software produktes ist 3 Agile Softwareentwicklung Die Agile Softwareentwicklung 1 ist eine relativ neue Methode innerhalb der Famil
103. a der Diplomarbeit erwerben bzw auf Grundlage und im Rahmen des Seminars ihre Bakkalaureatsarbeit theoretischer Teil verfassen Ebenso soll durch positive Kritik solcher Arbeiten bereits w hrend der Entstehungsphase F hrungs und Teamf higkeit ge bt werden aber auch unmittelbar Beitr ge zum Erfolg der Gesamtveranstaltung geliefert werden Methodisch baut dieses Seminar auf den Erfahrungen der Abwicklung von Konferenzseminaren Organisationsform des Seminars aus Software Engineering der letzten Jahre auf Aufgrund der unterschiedlichen Zielgruppen und auch aufgrund der hohen Teilnehmerzahl ist die Abwicklung w hrend des Semesters nicht rein elektronisch Dennoch wird es eine umfangreiche Vorbereitungsphase geben auf die einige Referate Bl cke aufbauen Details zur Abwicklung Terminplan und Beurteilungsraster finden Sie in der Seminarordnung in CLAROLINE Auf die Unabdingbarkeit der laufenden Mitarbeit und der strikten Einhaltung der als Fallfristen definierten Zwischen Abgabetermine wird nochmals explizit hingewiesen 155 159 Anhang 3 Seminar aus Angewandter Informatik Sommersemester 2004 R Mittermeir Extended Abstracts Liebe Kolleginnen Liebe Kollegen Jeder von uns hat schon gen gend Abstracts gelesen Daher haben wir in der Regel keine M he ein gutes Abstract zu schreiben Wir m ssen lediglich ein paar Aspekte ber cksichtigen Allerdings haben wir solange wir noch nicht am wissenschaftlichen Qualit
104. aare ab wechseln Ein jedoch nicht unwesentlicher Faktor ist der Kunde als Qualit tssicherungsinstrument Durch die Einbindung des Kunden in den Qualit tssiche rungsprozess wird gew hrleistet dass seine Anforde rungen erf llt und berpr ft werden Wie bereits er w hnt unterscheiden sich agile Methoden hinsichtlich der Dokumentationst tigkeit gegen ber den traditio nellen Methoden Es scheint dass in XP kein Platz f r Dokumentation besteht Die Relevanz einer Doku mentation 21 wird aber bei genauerer Betrachtung bewusst vor allem wenn Kommunikation in den Vor dergrund tritt Kommunikation bedingt ab einer be stimmten Projektgr e Dokumentation besonders wenn diese durch Vergaberichtlinien oder Standard isierungsma nahmen erforderlich ist 20 XP versucht dieses Fehlen durch die Codierungsstandards und den Kundenkontakt wettzumachen Hierbei ist h ngt es aber sehr stark von dem Kunden ab ob dieser auf Dokumentation verzichten kann beziehungsweise auf wie viel Dokumentation der Kunde besteht XP in der Grundidee verzichtet zu Gunsten von Testf llen auf ausf hrliche Dokumentation dort wo es erw nscht ist ist die Verwendung bei Bedarf jederzeit m glich 5 5 Vor und Nachteile XP verspricht auf Grund der Einfachheit die Ent wicklung von leichtverst ndlichem Code dies ist durch die Einhaltung von Programmierstandards und der starken Codezentriertheit m glich Vorausgesetzt ist hierbei die strikte Einhaltung de
105. aceability gibt es eigentlich nur 2 gro e Gruppen der Teilnehmer die Probleme haben und ihren Bedarf irgendwie zum Ausdruck bringen wollen erstens die SW Entwickler und zweitens die End User Die SW Entwickler ben tigen Hilfe bei Verbindung des Pre Traceability mit ihrer Arbeit Auf Grund dessen muss der SW Entwickler dem Pre Traceability eine h here Priorit t und somit mehr Zeit zuweisen als vergleichsweise der erheblichen System verbesserung 10 Die Endbenutzer benutzen Pre Traceability um ihre Bed rfnisse zum Ausdruck zu bringen Die nun ange f hrten Probleme und die dazugeh rige Graphik soll dies veranschaulichen 1 e Ein stereotypischer Endbenutzer kann nicht vor bestimmt werden Seine Anforderungen unter scheiden sich und sind h ufig inkonsistent e Die Quantit t die Uneinheitlichkeit und die Tie fe des Details der ben tigten Informationen schlie t Pre Definitionen aus e Auf Grund der Unf higkeit vorzubestimmen wie jeder Zugang zu den Informationen be kommt und wie sie darzustellen sind muss dies gefordert und zu Beginn in der Spezifikation festgelegt werden e Vertrauen auf pers nlichen Kontakt und Kor rektheit da es immer irgendwelche Daten gibt die veraltert unbrauchbar undokumentiert und unzug nglich sind e Jeder Endverbrauchkontext stellt einzigartige Anforderungen aus also entstehen Probleme wenn Endbenutzer nicht die F higkeit haben die Informationen zu filtern und zug
106. adaptiert worden sind Grunds tzliche gibt es wenige unterschiedliche Ans tze Beispielsweise f r Ans tze die auf die Poisson Verteilung aufbauen Non Homogeneous Poisson Process NHPP wie auch Enhanced NHPP ENHPP Modelle F r F lle wo keine Fehler Daten zur Verf gung stehen finden statistische Techniken wie Maximum Likelihood Estimation MLE gro en Anklang 5 Schlussfolgerung Wie der Arbeit zu entnehmen ist stellt die Zuverl ssigkeits Analyse eine entscheidende Rolle im Software Qualit tsprozess dar Um den optimalen Release Zeitpunkt zu finden reicht dies aber bei Weitem nicht aus In den meisten F llen werden solche Entscheidungen durch firmenpolitische Faktoren mit beeinflusst Unterst tzend einwirken k nnen darauf Software Reliability Modelle die dazu beitragen abzusch tzen wie viele Fehler sich noch in einem Produkt befinden Man muss den Tradeoff wagen auch in gewissen Situationen lieber erstmal ein nicht ganz fertiges Produkt auf den Markt zu bringen bevor die Konkurrenz sich in seinem Kundenkreis ausbreitet Ich w rde deshalb meinen dass der Einsatz von Software Reliability Growth Models sehr wichtig ist Man wird in vielen F llen Anpassungen vornehmen m ssen um die eigene Systemlandschaft nachzubilden Einen groben Aufschluss kann man daraus aber auf jeden Fall ziehen 6 Referenzen 1 Alan Wood Software Reliability Growth Models Assumption vs Reality Eighth International Symposium on So
107. alyse von Klassen und Packages mit der enthaltenen GUI als auch der Batch Betrieb zur automatisierten Erzeugung von Reports m glich Clark beschreibt sogar wie man JDepend mit JUnit kombinieren kann um den Build Proze scheitern zu lassen wenn sich die Werte der Metrik au erhalb der festgesetzten Schranken befinden Auch die Integration mit Ant und Maven ist vorgesehen Die Reports k nnen mit steigender Klassenanzahl schnell recht umfangreich werden da wirklich alle von Martin vorgeschlagenen Kennzahlen errechnet werden Die Dokumentation von JDepend ist sehr zufriedenstellend und es scheint immer noch weiterentwickelt zu werden 4 4 CCCC 18 Diese Metrik Software wurde eigentlich fur C C geschrieben aber inzwischen unterst tzt sie auch Java CCCC bietet zahlreiche klassische Metriken LOC CC Fan in Fan out Weighted Methods per Class WMC ist die einzige bisher implementierte OO Metrik Auch CCCC ist freie Open Source Software 4 5 Fazit Das Angebot freier Software ist etwas entt uschend F r OO Metriken finden sich kaum Werkzeuge traditionelle Metriken sind noch eher vertreten Anscheinend ist in der Open Source Community kaum jemand vom Nutzen der OO Metriken berzeugt Dies mag wohl auch an der Art und Weise der Softwareentwicklung und der Mentalit t in der Community liegen 5 Kritikpunkte Auch wenn Software Metriken das Potential haben den Softwareentwicklern die Arbeit mit wertvollen quantifiziert
108. anderem auch mit Lack of Cohesion in Methods LCOM einer Metrik die dazu dient mangelnde Koh sion festzustellen Dazu wird in einer Klasse C mit n Methoden Mi Ma bis Mn zu jeder dieser Methoden die Menge der verwendeten Instanzvariablen 7 bestimmt Mit diesen Mengen J bis I werden in jeder Kombination Schnittmengen gebildet und dabei gez hlt wie oft diese Schnittmenge leer ist und wie oft nicht P h 5 1 9 Q Fi GN L 0 Wenn P gt Q dann LCOM P Q sonst LCOM 0 Je fter es keine berschneidung gibt desto h her ist die Zahl der Methoden zwischen denen ber die verwendeten Instanzvariablen kein direkter Zusammenhang besteht und desto h her ist somit der Mangel an Koh sion LCOM in der Klasse 2 Andere Autoren entwickelten neue Varianten und Definitionen von LCOM 3 So haben etwa Hitz und Montazeri eine graphentheoretische Definition von LCOM erarbeitet die allerdings auf einer etwas anderen Interpretation dieser Metrik von Li und Henry basiert Sp ter haben Hitz und Montazeri eine neue Variante von LCOM vorgestellt die auch Methodenaufrufe ber cksichtigt In Henderson Sellers LCOM Metrik werden Mengen von Methoden gebildet die auf gemeinsame Variablen zugreifen umgekehrt wie in der urspr nglichen LCOM Metrik von Chidamber und Kemerer Aus dieser Variante wiederum wurde eine neue Metrik von Briand et al entwickelt die auch geerbte Methoden und Variablen in die Berechnung aufnim
109. ann eine Vielzahl anderer Vorteile aus der Verwendung von Messprogrammen gezogen werden 2 4 6 GQM strukturiert die ber Metriken gesammelten Daten und verbindet sie mit tats chlich gestellten Fra gen w hrend ohne die Verwendung von GQM unter Umst nden unstrukturierte Daten gesammelt werden GQM unterst tzt die Verbesserung von Arbeitsab l ufen innerhalb einer Organisation indem es fokus siert darstellt wo Verbesserungen m glich sind Daneben dokumentiert es ob durchgef hrte Ver nde rungen eine Verbesserung bringen Durch die direkte Einbeziehung der Mitarbeiter in den GQM Prozess m ssen sich diese mit den Quali t tssicherungma nahmen auseinandersetzen Dies erm glicht es ihnen sich mit den Qualit tszielen st r ker zu identifizieren Durch die verst rkte Zusammenarbeit der Mitarbei ter die die Durchf hrung eines GQM Programms mit sich bringt wird das Gruppengef ge verst rkt und die Kommunikation gesteigert Der finanzielle Vorteil an sich ist schwer zu mes sen da eine starke Wechselwirkung zwischen den ver schiedenen Einflussfaktoren besteht Jedoch bringt eine Verbesserung der Prozessabl ufe und Arbeitsme thoden oft auch eine h here Produktivit t der Mitarbei ter und damit reduzierte Kosten mit sich Au erdem wirkt sich eine gute Qualit t der Produkte positiv auf das Gesamtbild des Unternehmens aus was zus tzliche Auftr ge zur Folge haben kann 4 GQM in der Praxis 4 1 Praxisbeispie
110. asen unterteilt ist in Planung und in Architekturdesign Die Entwicklungsphase oder auch Spielphase genannt ist der agile Teil von Scrum In dieser Phase wird die Software durch so genannte Sprints entwickelt Diese Sprints sind iterative Zyklen mit den traditionellen Phasen Bedarfsanalyse Design Entwicklung und Auslieferung Innerhalb dieser Sprints k nnen beliebige Techniken wie zum Beispiel eXtreme Programming zur Softwareentwicklung verwendet werden In der Nachspielphase wird das Produkt fertig gestellt und ausgeliefert In Scrum h ngen die zu setzenden Qualit tssiche rungsma nahmen sehr stark von den in der Entwick lungsphase eingesetzten Techniken ab Scrum ist ge eignet f r kleine Teams Schwaber und Beedle 15 schlagen ein Team von f nf bis neun Mitglieder vor Dar ber hinaus sollten mehrere Scrumteams gegr ndet werden Wie bei allen agilen Methoden f llt auch bei Scrum dem Team und den Teamrollen eine besondere Bedeutung zu Das Scrumteam selbst hat die Verantwortung und die Autorit t selbst Entscheidun gen zu treffen und sich dementsprechend zu organisie ren Das Scrumteam ist auch f r die Qualit tssicherung der einzelnen Sprints verantwortlich Der Scrum Master ist f r die Einhaltung der Spielregeln zust ndig und dient als Kommunikationsschnittstelle zwischen Team Management und Kunde Der Kunde ist in die Entscheidungen f r die Anforderung der Sprints eingebunden Scrum wird oft als Rahmenger st f r den E
111. assungen Dienstage nach Vereinbarung 1 April Zwischen und Kurzpr sentationen mit Feedback aus Plenum 5 min Vortr ge ab Mitte Mai F lligkeitstermine f r Langfassungen unterschiedliche Termine f r unterschiedliche Zielgruppen 10 Tage Reviewing Periode 4 Tage Zusammenfassungs Periode ab Anfang Juni voraussichtlich mit Zusatz Terminen Vortrags Termine Abzugebendes Material Extended Abstracts Titel halb bis max einseitige Darstellung ber Ziel und Inhalt der Arbeit Orientierungsgr e 2000 bis 3000 Zeichen Inhaltsverzeichnis zweistufig Angabe der drei wichtigsten Arbeiten auf die sich das Referat st tzen wird Reviews der extended abstracts Auf bereitgestelltem Formular Langfassung F r Kurzbeitr ge zweist ndiges Seminar maximal vier Seiten f r Vollbeitr ge Bakkalaureatsarbeiten dreist ndiges Seminar acht bis zehn Seiten in klassischem acm oder IEEE Proceedings Style wird bereitgestellt Das selbst gesteckte Ziel und der daf r erforderliche Inhalt ist innerhalb dieses Platzes samt erforderlicher graphischer Darstellungen unterzubringen Reviews der Langfassungen Vortrag mit zugeh rigem Pr sentationsmaterial Vortragsdauer f r Kurzbeitr ge max 15 min f r Hauptvortr ge Bakkalaureats Vortr ge max 30 min Beurteilungsschema Beurteilt wird die auf Individualleistung und Mitarbeit beruhende Gesamtleistung bestehend aus Qualit t des extended Abstracts 20 Leistungen im Review
112. ate errechnet Eine Erh hung der Qualit t der Sch tzung kann mittels Multiplikation vorbe stimmter Einflussfaktoren deren Werte aus einer Ta belle zu entnehmen sind erfolgen Seit Entwicklung von COCOMO 81 haben sich im Bereich Softwareentwicklung drastische Ver nderun gen ergeben die eine berarbeitung des urspr ngli chen Modells unumg nglich machten COCOMO 81 basiert auf dem Wasserfallmodell was heute als ber holt und veraltert gilt und auf der Annahme dass Software immer neu entwickelt wird Mittlerweile spricht man von komponentenbasierter Softwareent wicklung wo bereits fertige Komponenten zusammen gef gt werden und es so zu einer Wiederverwendung der Software kommt Des Weiteren wurde die Ent wicklung von Prototypen nicht ber cksichtigt Heute ist dies jedoch eine weit verbreitete Methode Auch werden viel mehr gekaufte Subsysteme eingesetzt Programmiersprachen der 4 Generation 4GLs ver 51 159 wendet vorhanden Software wird umgestaltet und daraus neue kreiert und h ufig wird die Entwicklung durch ein CASE Werkzeug unterst tzt Um all diese nderungen auch in der Aufwandssch tzung dement sprechend zu ber cksichtigen berarbeitete Barry Boehm dahingehend das Modell und ver ffentlichte im Jahr 2000 COCOMO II SOMMOI 2 2 Zielgruppen F r wen eignet sich berhaupt COCOMO II Diese Frage soll hier im Folgenden gekl rt werden Man geht hier wie Abbildung 1 zeigt von f nf verschiedenen
113. ation Score 100 so ist die verwirklicht 6 Testmenge mutations ad quat mutation adequate d h sie konnte alle Fehler finden 4 Zugriffsmodifikatoren in Java 6 Aufgrund des enormen Aufwands der Erzeugung Kapselung Kapselung ist ein Verfahrung zur Minimierung von und Ausf hrung von Mutanten sowie der Erkennung Modifi Gleiche Subklasse Selbes Anderes Anderes Beta ait Mutant d hied kator Klasse im selben Package Package Package von quivalenten utanten wurden verschiedene Package keine Subklasse keine Varianten des Mutationentests wie selective Subklasse Subklasse Mutation und weak Mutation entwickelt Der zuvor Private Ja Nein Nein Nein Nein i iti i Default beschriebene traditionelle Ablauf des Mutationentests a Ja Ja Ja Nein Nein ist aus Figure 1 ersichtlich Die mit gestrichelter Linie ktivit imd dabei Hand Protected Ja Ja Ja Ja Nein umrandeten Aktivit ten sin i a ei von an Public Ta Ta Ta Ta Ta auszuf hren Der Aufwand bel uft sich auf O N wobei N die Anzahl der Referenzen in einem Vererbung Programm darstellt 4 Vererbung ist ein Mechanismus der es erm glicht RR Eigenschaften und F higkeiten von Klassen an andere Prog input tesi Grass ren Klassen weiterzugeben 7 program I mutants test razesi Java unterst tzt keine Mehrfachvererbung Die Subklasse erbt die Variablen und Methoden ihrer Elternklasse und aller anderen Vorfa
114. auch internationale Kongresse ab 15 159 SQS ist seit 2002 auch auf der CeBIT vertreten und wird auf Webseiten wie www aboutvb de ein deutsches Webmagazin in h chsten T nen gelobt Auch die deutsche Telekom Gruppe l sst nach Anga ben von SQS selbst und www aboutvb de ihre Software in mehreren europ ischen L ndern von SQS testen 6 3 Government of British Columbia Genauer gesagt ist es die Homepage des Ministeri ums f r Sustainable Resource Management des Governments of British Columbia Diese Seite besch ftigt sich mit Standards f r Abnahmetests die f r die Applikationsentwicklung innerhalb des Minis teriums verwendet wird Darin sind auch ein Template und Instruktionen f r die Entwicklung eines Akzep tanztestplans enthalten Das Ministerium unterscheidet drei Arten von Akzeptanztests den New System Test das ist das Testen v llig neu entworfener Software den Regres sion Test durchgef hrt wenn ein bereits existieren des Softwaresystem derma en ge ndert wird dass ein v lliges Neutesten stattfinden muss und der Limited Test auch hierbei besteht das System bereits die nderungen sind jedoch so minimal dass nur die ge nderten Features getestet werden m ssen wobei auch das Limited Testen noch in drei Arten unterteilt wird auf die ich hier aber nicht n her eingehen m chte Bez glich des Test Kriteriums werden sechs F lle unterschieden 1 neue Applikation die keine existiere
115. bestimmten Meilensteines Diskussionen ber Kosten Zeitpl ne und Leis tung Entscheidungen ber Risiken Entscheidungen ber Fortschritt und Verbesserun gen von Software Reuse Outsourcing Tools 2 5 Tools Es gibt sowohl kostenlose private Tools als auch kommerzielle Tools die bei der Aufwandssch tzung mit COCOMO I den Benutzer unterst tzen sollen Hier sollen drei n tzliche Tools kurz vorgestellt wer den UNIMO4 1 QuickSoft Calculator Der QuickSoft Calculator ist zu finden unter http www pm99 de oldhome quicksoft index ht m QuickSoft wurde speziell f r Studenten von Dr Siegfried Seibert Professor an der Fachhoch schule Darmstadt entwickelt um ihnen den prak tischen Einsatz zu erleichtern und um das Modell auszuprobieren Dieses Tool steht in Form einer Web Applikation zur freien Verf gung Es ist sehr bersichtlich und leicht handhabbar 2 Costar Costar ist ein kommerzielles Tool Die Einzelli zenz kostet 1 900 USD die Unternehmenslizenz liegt bei 25 000 USD N here Informationen zum Produkt sowie eine kostenlos downloadbare De moversion findet man unter http www softstarsystems com index htm 3 Construx Estimate 2 0 Construx bietet auf seiner Homepage dieses Tool zum freien Download mit eingeschr nkter Lizenz vorher ist allerdings eine Registrierung notwen dig an Zu finden ist das Tool unter http www construx com resources estimate inde x php Die bekanntesten Partn
116. bst festgelegt Diese Standards sollen zur Qualit tssicherung beitragen au erdem soll es erm glicht werden das Einarbeitungszeiten bei Ausf llen oder Wechseln kurz ausfallen Pair Programming Bei jedem Entwicklungs schritt bei XP wird von Tasks gesprochen werden zwei Entwickler ben tigt Diese Anforderung soll auf der einen Seite sicherstellen dass die Standards ein gehalten werden und auf der anderen Seite soll da durch zur Fehlervermeidung beigetragen werden Ge treu nach dem Motto Vier Augen sehen mehr als zwei Des Weiteren wird sichergestellt dass mehrere Programmierer Kenntnisse ber den Code besitzen um so Ausf llen vorzubeugen Die Programmierer wech seln sich untereinander ab au erdem tauschen die Paare sich aus Diese Praktik wird oft als Verschwen dung von Ressourcen gesehen und gilt daher als um strittenste Praktik von XP Sie wird jedoch innerhalb von XP als wesentliches Mittel zur Qualit tssicherung verstanden Unit Tests Die Tests werden vor Beginn eines Tasks geschrieben dies soll dem Programmierer nochmals verdeutlichen welche Funktionalit t bereit gestellt werden soll Des Weiteren wird sichergestellt dass die Implementierung der gew nschten Funktio nalit t gerecht wird Functional Tests Der Kunde entwickelt Funkti onstests Akzeptanztest dies geschieht je nach Kenntnis des Kunden Entweder entwirft der Kunde diese Tests selbst oder mit Hilfe eines Testers bezie hungsweise eines En
117. c of the 10th International Symposium on Software Reliability Engineering ISSRE 99 November 1999 7 Y Labiche P Th venod Fosse H Waeselynck and M H Durand Testing Levels for Object Oriented Software Proc 22nd IEEE International Conference on Software Engineering ICSE Limerick Ireland June 2000 137 159 Mutationentest Objektorientierte Mutanten f r Java Programme Innerwinkler Daniela Gunar M tzler 0060550 0060396 dinnerwi gmaetzle edu uni klu ac at Abstract Der Mutationentest ist eine auf Fehler basierende Testmethode mit deren Hilfe die Effektivit t von Testdaten bewertet werden kann Der traditionelle Test kann bestimmte Arten von Fehlern die in objektorientierten Programmen auftreten bersehen Die Ursache daf r ist die Tatsache dass Mutationsoperatoren aus Studien mit nicht objektorientierten Programmiersprachen wie Fortran oder C abgeleitet wurden und somit nur die Merkmale prozeduraler Programmiersprachen unterst tzen In der folgenden Abhandlung wird anhand der Programmiersprache Java auf spezifische Fehler eingegangen die durch die Merkmale objektorientierter Sprachen entstehen k nnen und betrachtet wie bestehende Ans tze durch die Einf hrung neuer Mutationsoperatoren zu passenden Mutanten f hren k nnen Die Frage inwieweit marktreife Tools f r objektorientiertes Mutationentesten verf gbar sind und ob dieser Ansatz den Sprung aus der Theorie in die Praxis geschafft hat
118. ch ausgef hr ten Aktivit ten zeigt in welch detaillierten technischen Level der K ufer einbezogen wird Diese Schl ssel punkte inkludieren Planung und administrative Ver antwortlichkeiten Ziele Ann herungen rtliche und automatische Anforderungen Mitarbeiterverantwort lichkeiten und Dokumentation f r das Software Akzeptanztesten 4 5 STEP 5 Triff die Akzeptanzentscheidung Endg ltige Softwareakzeptanz bedeutet normaler weise dass der Vertrag und das Projekt komplettiert wurden mit Ausnahme von M ngeln bei der Akzep tanz Die endg ltige Bezahlung der Software wird get tigt und der Entwickler hat keine weiteren Entwicklungsverpflichtungen Softwareakzeptanz ist ein vertraglicher Prozess Be stimmte Arten von Software m ssen die Akzeptanz 13 159 bestehen noch bevor die Anforderungen vollst ndig spezifiziert wurden Dazu geh ren e Software die die Entwicklung des Systems unterst tzt Software um das System zu betreiben Existierende Software f r die Eingliederung in das System Rekapitulieren wir noch einmal die wichtigsten Punkte 1 Der die Entwickler muss m ssen den Akzep tanzkriterien die der K ufer entwickelt hat zustimmen 2 Der K ufer muss die Akzeptanzkriterien basierend auf den Systemanforderungen defi nieren 3 Andere Projektcharakteristiken wie spezielle Methodiken m ssen in die Definition der Ak zeptanzkriterien einbezogen werden 4 Akzeptanzentscheidungen basieren a
119. ch ein Zitat verwenden das ich bei meinen Recherchen f r diese Arbeit gefunden habe und das meiner Meinung nach vieles ber die Verwendung von Software in der Automobilindustrie aussagt Weil Fahren ohne Software hard ware 10 6 Referenzen 1 http www alldengineers com Datum April Mai 2004 2 http www oeamtc at Datum April Mai 2004 3 Auto Touring Clubmagazin des Oamtc Ausgabe April 4 2004 zu finden u a unter http www oeamtc at Datum April Mai 2004 4 Zeitschrift AUTO amp ELEKTRONIK Ausgabe April 4 2002 zu finden auch unter http www all electronics de article 0 13013001 9c915fb430e html Datum April 2004 5 Prof Dr M Broy Dr M von der Beeck I Kr ger TU M nchen SOFTBED Problemanalyse f r ein Gro verbundprojekt Systemtechnik Automobil Software f r eingebettete Systeme 12 M rz 1998 zu finden unter http www bmbf de pub softbed pdf Datum April Mai 2004 6 P Kleiner Die Entwicklung von Software f r den PKW ATZ 10 2003 Jahrgang 105 zu finden unter http www alldengineers com Datum April Mai 2004 7 http mitglied lycos de Autoelektrik Zho htm Datum Mai 2004 8 http www sqs de Datum April Mai 2004 9 http www automobil forum de themen 00136 index php Datum April Mai 2004 10 Dr U Weinmann Anforderungen und Chancen automobilgerechter Software Entwicklung BMW Car IT GmbH M n
120. ch hier wird kein Grenz wert angegeben Vielmehr wird darauf hingewiesen dass jedes Projekt eine Menge von Klassen haben soll die sp ter wiederben tzt werden k nnen und dass jedes Projekt eine Menge von Klassen wiederben tzen sollte 4 3 Weitere Metriken In 19 2 17 16 und 6 findet man weitere Auflistun gen von objektorientierten Softwaremetriken Unter diesen Metriken ist den Autoren die Metrik VLT Volatility 16 besonders aufgefallen da sie auf Wahrscheinlichkeit beruht Die Metrik stellt hierbei ein Wahrscheinlichkeitsma f r die nderung eines Objekts dar wobei die zugrundliegenden Wahrscheinlichkeiten vom Designer subjektiv eingesch tzt werden m ssen Weitere interessante Metriken sind zum Beispiel MEF Main tainability Efficiency sowie RUF Reuse Frequency welche die Wartbarkeitseffizienz von Methoden bzw die Frequenz der Wiederverwendung im System messen siehe 19 5 OBJEKTORIENTIERTE METRIKEN amp GRENZWERTE Bei der Verwendung von Metriken und der Interpretation der Ergebnisse ist folgendes zu beachten Wann gibt ein Messwert Anlass f r Gegenma nahmen Gesucht ist also eine Funktion welche die Menge der Messwerte in auff llige und unauf f llige Werte aufteilt 12 Gesucht sind also Grenz Werte die f r die Interpretation von Messergebnissen verwendet werden k nnen und die dabei helfen Probleme im System aufzusp ren Der Begriff Grenz wert kann dabei folgend definiert werd
121. che Tests problematisch denn wenn das User Interface nicht in dieser Art und Weise spezifiziert ist wie soll man es dann Testen Und vor allem wie soll man Tests schreiben die fehl schlagen wenn das Interface schlampig und schwer zu 16 159 verwenden ist und gut ausfallen wenn es sauber ein fach und klar ist Der meiner Meinung nach interessanteste Beitrag stammt einem pensionierten israelischen Air Force Offizier der sechs Jahre lang der Kopf des Flugsimu latoren Softwareentwicklungsteams war und auf diesem Gebiet viel Erfahrung mit Akzeptanztests gesammelt hat Bei ihm war es so dass die meisten Kunden den Entwickler die Abnahmetests schreiben lie en denn die Spezifikationen des Kunden auf diesem Gebiet sind oft recht kurz wie etwa Ich brauche einen Flugsimulator um Notfallprozeduren und Instrumentkampfregeln f r dieses Flugzeug zu trainieren Der Auftragnehmer muss dann die Anfor derungen selbst analysieren und aufschreiben Es gibt zwar einen Formalen Vertrag mit dem Kunden aber der Entwickler agiert selbst als Kunde und lenkt das Projekt in die Richtung die seiner Meinung nach ein geschlagen werden sollte Er schreibt die Geschichten schreibt die Akzeptanztests priorisiert usw Der Kun de bekommt die fertigen Prozeduren vorgelegt stimmt zu und sieht bei der Ausf hrung der Tests zu Diese Tests dauern 1 bis 3 Wochen Zus tzlich bekommen die Kunden einige Tage Free Flight in denen sie selbst noch die S
122. chen Juni 2002 11 http www programmingresearch com Datum April Mai 2004 12 H Trauboth Software Qualit tssicherung Konstruktive und analytische Ma nahmen Handbuch der Informatik Oldenburg 1993 Bd 5 2 13 G E Thaller Software Qualit t Entwicklung Test Sicherung Informatik Management Sybex D sseldorf 1990 14 A Sczepansky QA Systems GmbH MISRA Programmierstandard Qualit tssicherung in der Praxis F r und Wider Programmierstandards zu finden unter _ http www weltwissen24 de fsqrs termine 020606 MISRA pdf Datum April Mai 2004 15 http www eetimes de at news OEG20040216S0008 Datum Mai 2004 16 http adac de Datum April Mai 2004 17 http www auto motor und sport de Datum April Mai 2004 18 M Broy Software im Automobil Potentiale Herausforderungen Trends http www bmw carit de gi praesentationen GI_2003_ 47 159 Praesentation_Software_ im Automobil pdf Datum April Mai 2004 19 http www all electronics de Datum April Mai 2004 20 http www bmw carit de Datum April Mai 2004 21 http www ga systems de Datum April Mai 2004 22 http www telematik institut org presse_und_ medien pressemitteilungen 2002 pm41_02 html Datum April Mai 2004 23 http www elektronikpraxis de fachartikel druck ep_fachartikel druck 561630 html Datum April Mai 2004 24 T Jungmann Aut
123. chon vor einem Vertragsabschluss einen m glichst konkreten Zeitplan zu erstellen der sowohl dem Kun den als auch dem Unternehmen eine gewisse Sicherheit bietet Denn nur Software der gen gend Zeit gewid met wird funktioniert im Allgemeinen zuverl ssig da sie optimal geplant designed programmiert ge testet und dokumentiert wird 4 Projektplanung F r jeden angehenden Informatiker aber auch In formatiklehrer stellt sich fr her oder sp ter die Aufga be das erste Projekt zu planen leiten Im Allgemeinen kann man hier leider nicht auf Zeitpl ne zur ckgreifen an denen man sich orientieren k nnte Auch die Er fahrung wie viel Arbeit man in einer gewissen Zeit fehlerfrei erledigen kann und wie viel Zeit die einzel nen Aufgaben in Anspruch nehmen fehlt meist Im industriellen Bereich bieten sich f r die Zeit sch tzung ver ffentlichte Daten unterschiedlicher Soft wareunternehmen bez glich der Produktivit t die z B in Lines of Code LOC angegeben wird an Im per s nlichen Softwareentwicklungsbereich erweisen sich diese Daten jedoch als unbrauchbar Jedoch wei hier der einzelne ber sein Leistungspotential relativ genau Bescheid Allerdings empfiehlt es sich hier auch Me thoden die im Folgenden vorgestellt werden anzu wenden um eine objektivere Sicht auf die Leistung zu erhalten Eine Methode die man anwenden kann wenn keine Daten vorliegen wollen wir in diesem Kapitel insbe sondere f r a
124. ckelte Programm den im Vorhinein definierten Anforderungen ent spricht F llt ein System beim Abnahmetest durch geht es wieder zur ck und wird berarbeitet Besteht das System den Test dann ist die Entwicklung abge schlossen die Verantwortung geht vom Verk ufer auf den K ufer ber und das System befindet sich in der Wartungsphase 2 Anforderungsanalyse Abnahmetest Systementwurf Systemtest Modulentwurf Integrationstest Codierung Unit Test Abbildung 1 klassisches Testplanungsmodell 3 In Abbildung 1 sieht man deutlich die Zusammen h nge zwischen den Entwicklungs und Testschritten W hrend der jeweils links stehenden Phase k nnen die Testf lle geplant werden die in der rechts stehenden Testphase dann abgepr ft werden Hieraus erkennt man dass die Testf lle f r den Abnahmetest aus der Anforderungsanalyse hervorgehen 3 Deswegen soll te man die Aussage von Dorothy Graham beherzigen Good requirements engineering produces better tests good test analysis produces better requirements 4 Der Unit Test sucht Fehler in den kleinsten test baren Einheiten Units wie etwa in Unterprogram men Funktionen Methoden auf Basis der Imple mentierung Der Integrationstest zeigt ob die Kombina tion von Komponenten inkorrekt oder inkonsistent ist obwohl die einzelnen Komponenten f r sich zufrieden stellend sind dh er testet besondere Schnittstellenprob leme auf Basis des Modulentwurfs Wohingegen der S
125. ckward to Requirements Hierbei wird ber pr ft ob das Systems die Anforderungen richtig um setzt Weiters muss hier das Prinzip des Gold plating z B ein Design f r das keine Anforderungen beste hen vermieden werden Forward to Requirements Bei diesem Punkt geht es um die nderung der Bed rfnisse des Kunden In technischen Annahmen kann es eine radikale Neuver anlagung der Anforderungen bedeuten Backward from Requirements Die zu Grunde liegenden Anforderungen der Beitragsstruktur sind entscheidend wenn man Anforderungen besonders in einem hohen Grade validiert 69 159 Design Documents Components Backward from traceability n Forward from traceability En ly Forward to traceability i Backward to traceability ie H PRE TRACEABILITY i POST TRACEABILITY Abb 3 Die 4 verschieden Typen des RT 13 Einerseits dient Traceability from the Require ments Specification vom Entwurf bis zur Implemen tierung des besseren Verst ndnisses des gegenw rtigen Systems Andererseits muss der Entwicklungsprozess To the Requirements Specification nachvollziehbar sein um die Anforderungen an sich zu verstehen und sie an ihren Ursprung zur ck zu verfolgen 5 Wie bereits bekannt ist dient Requirements Tracea bility zur Entwicklung von Software Systemen mit sehr hoher Qualit t W hrend das Traceability der Verfeinerung der Entwicklung und des Gebrauches von
126. d Diese Eigenschaften sind wichtig um zu verfolgen dass die Anforderungsspezifikation in den verschiede nen Situationen w hrend der Entwicklungsprozesse verwendet werden kann Die Spezifikation muss eine komplette und gleich bleibende Ansicht des Systems reflektieren die nicht in den unterschiedlichen Weisen gedeutet werden kann 3 1 Pre Traceability Wie schon notiert wurde wird Traceability als die F higkeit beschrieben und definiert um das Leben einer Anforderung in beiden Richtungen zu verfolgen Die Pre Traceability behandelt weiters die Aktivit ten die vor oder und w hrend der RS auftreten Hier geht es aber nur um die R ckw rtsrichtung 6 Die R ckw rtsrichtung entspricht der Pre Anforderung dass hei t die relevanten Aspekte die jene Anforderung nach oder w hrend ihres Lebens durchl uft werden in die Dokumentation miteinbezo gen Pre Traceability h ngt von der F higkeit der Nachvollziehbarkeit im Prozess der Produktion und der st ndigen Verfeinerung zu ihrem Ursprung ab nach vor sowie auch zur ck Es muss auch gew hrleistet werden dass alle Statements von verschiedenen Quel len in die vorhandene Spezifikation integriert werden Es ist auch offensichtlich dass die Eigenheiten der Beteiligten eine gro e Rolle spielen und sich im Bezug auf den Support der Anforderungen auswirkt 7 3 1 1 Probleme des Pre Traceability Im Prozess des Requirements Tracings speziell hier beim Pre Tr
127. d Funktionalit t sicherzu stellen die vom Kunde gefordert wurde Wie zu entnehmen ist verwenden bei WST alle Re quirements Traceability als ein wichtiges Qualit tsma nagementwerkzeug Vom Top Management bis hinun ter zum Systemwartungspersonal alle glauben daran dass RT f r einen erfolgreichen Abschluss unentbehr lich sei 5 Qualit t und Requirements Traceability Die Nachfrage von Qualit tskontrolle Nachvoll ziehbarkeit und Dokumentation steigt st ndig an Wie sich aus der Arbeit schon herauskristallisierte ist es schwierig Benutzeranforderungen mit notorischer Genauigkeit zu erreichen da sie h ufig instabil sind und ber die Zeit immer wieder neu definiert werden Au erdem neigt die Benutzerzufriedenheit eine kollek tiv und subjektive Angelegenheit zu sein Qualit tsan forderungen werden im Allgemeinen aus externen Standards oder Politikdokumenten importiert Qualit t h ngt mit der bereinstimmung der Sys temspezifikation mit den Systemeigenschaften und mit der Kundenzufriedenheit zusammen RT hat Einfluss auf jeden dieser Faktoren Urspr nglich wurde RT nur zur berpr fung der geforderten Systemf higkeiten und eigenschaften verwendet IT Organisationen die Anforderungen nicht nachvollzogen dachten h ufig dass es eine blo e bung in Gr ndlichkeit und Voll st ndigkeit sei und die Qualit t in gelieferten Eigen schaften und Funktionalit ten ausgedr ckt ist Jedoch durch das Aufkommen der Anf
128. dass die Dokumentation alleine nicht ausreicht eine Benutzerschnittstelle verst ndlich zu machen und ein schlechtes Design der Benutzerschnittstelle kann dadurch nicht kompensiert werden somit ist Dokumentation immer als erg nzend zu betrachten Dokumentationen sollten s mtliche Funktionen und Aspekte eines Programms nachlesbar machen speziell das Verhaltensmodell das dem Produkt zugrunde liegt sollte klar ersichtlich sein Wiederholungen und unn tige Komplexit t sind hingegen st rend wenn eine Dokumentation zu kompliziert ist schlie en die Benutzer daraus auf das Programm und werden abgeschreckt Von den verschiedenen Formen der Dokumentation sind Tutorials f r Anf nger am n tzlichsten und Referenz Manuals f r Experten von Interesse User Guides sind vor allem f r die durchschnittlich erfahrenen Benutzer interessant Als Alternative zu schriftlichen Manuals stehen heutzutage meist online Hilfssysteme zur Verf gung die die gleiche Funktion haben wie die Handb cher Als eine Abart kann ein Hilfesystem so entwickelt werden dass es das Verhalten des Benutzers berwacht und bei Fehlverhalten von selbst Hilfestellungen gibt 7 Schulungen sind die letzte hier erw hnte Methode um Benutzer mit einem System vertraut zu machen Sie finden stets erst nach Fertigstellung des Produkts statt und k nnen somit als teuer eingestuft werden Sie finden dort Anwendung wo Programme so kompliziert sind dass sie nicht intuitiv verstanden
129. definierten inhaltlichen Konzepten folgen 2 4 Volumen Das Volumen eines Softwareprodukts wird be stimmt durch die Anzahl der Informationen die f r seine korrekte Erstellung Nutzung Wartung Erweiterung nderung oder Verwaltung verar beitet und verstanden werden mu 14 Im Normalfall sind gro e Objekte schwieriger und kompli zierter zu verstehen als kleinere Gro e Objekte k nnen oft durch Zerlegen in mehrere kleine in sich geschlossene Einheiten an Komplexit t verlieren Da gro e Objekte oft speziell auf eine Applikation angepasst sind k nnen sie kaum in anderen Programmen wiederverwendet werden 2 5 Kapselung Unter Kapselung versteht man die Abgrenzung von Daten und Methoden vor externem Zugriff Wird Information be n tigt so werden diese ber wohldefinierte Schnittstellen bereitgestellt wobei die dahinterliegenden Daten und Me thoden nach au en hin nicht sichtbar sind Programmierer k nnen somit nur ber das Interface eines Objektes auf das Objekt zugreifen womit die Implementierung des Objektes nach au en hin nicht sichtbar ist 2 6 Unterschiede zu Metriken f r prozedurale Softwaresysteme Die Unterschiede zwischen prozeduralen und objektorient ierten Metriken legen sich schon im grundlegenden Design der zwei Paradigmen fest So werden in der objektorient ierten Technologie Objekte und nicht Algorithmen als die fundamentalen Baubl cke von Software verwendet Weiters zeichnet sich die objektorien
130. den Ursachen und Ergreifen von pr ventiven Ma nahmen Technologie Change Management Prozess Change Management Die Organisation stellt fest dass Wettbewerbsvorteile und finanzielle Stabilit t durch eine systematische und kontinuierliche Prozessverbesserung erzielt werden k nnen Sie kommt zu der Erkenntnis dass sie ihre Softwarequalit t ausbauen kann indem sie den Softwareprozess st ndig weiterentwickelt Diese Erkenntnis wie Ver nderungen herbeigef hrt werden k nnen spiegelt sich in den oben genannten SPBs wider Dieser SPB sollten in einer besseren Qualit t und Produktivit t resultieren 2 3 93 159 4 CMMI Vergleich zu CMM CMM Integration ist die neue tiberarbeitete Version vom Capability Maturity Model CMMI hat mehr und detailliertere Hinweise zur Umsetzung der Prozesse der einzelnen Stufen CMMI enth lt somit mehr Informationen aber nicht unbedingt mehr Anforderungen als CMM In CMMI wurden die Prozesse der einzelnen Stufen neu arrangiert Der Anwendungsbereich ist ber die Softwareentwicklung hinaus zur Systementwicklung und Kauf von Software erweitert worden CMMI definiert neben dem stufenf rmigen Modell mit den bekannten f nf Reifegraden auch ein kontinuierliches Modell indem ein Unternehmen unabh ngig von Reifegraden bewertet werden kann Bei der kontinuierlichen Darstellung ist eine feinere themenbezogene Darstellung der Reife einer Organisation m glich indem es pro Schl ssel
131. der Lage sein seine Arbeit zu dokumen tieren und zu analysieren dabei seine St rken und Schw chen zu erkennen und letztere auszumerzen in dem er seine Arbeitsweise in den betreffenden Situatio nen zu ndern versucht 4 F r das Zeitmanagement bedeutet das Um eine rechtzeitige Fertigstellung der Software zu garantieren muss jeder Einzelne seine Aufgaben pflichtgerecht er ledigen Dazu muss jeder Einzelne genau ber seine Arbeitsweise und seine Leistungsf higkeiten innerhalb 499 459 eines gewissen Zeitrahmens bescheid wissen Weiters wird von jedem Mitarbeiter erwartet dass er seine Ar beitszeit effektiv und effizient aber vor allem rea listisch plant Denn nur so kann ein m glichst rea listischer Projektplan erstellt und im Verlaufe des Pro jektes eingehalten werden Verfahren die in Folge vorgestellt werden k nnen dabei hilfreich sein 3 Zeitmanagement 3 1 Zeitmanagement als Basis hochwertiger Software qualitativ Eine wichtige Rolle in der Softwareentwicklung spielt sicherlich der Zeitfaktor Es ist offensichtlich dass durch eine mangelhafte Zeitplanung dem Kunden aber auch dem entwickelnden Unternehmen massive Kosten erwachsen welche das Unternehmen in den fi nanziellen Ruin treiben k nnen Aber auch der schlechte Ruf den ein Unternehmen durch eine nicht zeitgerecht gelieferte Software erh lt kann ver nichtende Auswirkungen haben Um dem vorzubeugen empfiehlt es sich m glichst s
132. der Zielplattform also des Prozessors und der restlichen Automobil Hardware erforderlich wird Daher ist das Merkmal der nderbarkeit der SW ebenfalls entscheidend f r die Qualit t Der rapide Anstieg der Softwarekomplexit t sowie der Zeit und Preisdruck bei der Entwicklung wirkt sich oft negativ auf die Produktqualit t aus und so w chst die Herausforderung an die Ingenieure die Qualit t zu sichern was jedoch meist schon daran scheitert dass SW Qualit t schwer messbar und definierbar ist 3 2 Probleme bei mangelnder Qualit t Der steigende Anteil der Elektronik in den Automobilen und dessen Komplexit t schlagen sich bereits in der Pannenstatistik nieder War nach Zahlen des ADAC 1998 die Elektrik und Elektronik noch in 45 2 Prozent aller Pannen die Fehlerursache so war sie 2001 schon zu 49 7 Prozent der Pannen das Problem Mithin war bei jedem zweiten liegen gebliebenen Auto die Elektronik schuld 15 41 159 Und die neuesten Zahlen die der ADAC bei einer Fachtagung im Jahr 2003 repr sentierte sprechen noch eindeutiger ber die unreife Software So sollen bereits 55 der Pannen ihre Ursache in der fehlerhaften Elektronik und SW haben In der letzten Zeit ist auch die Anzahl der R ckrufaktionen von Automobilherstellern auff llig gestiegen 10 der auftretenden Fehlfunktionen haben ihren Ursprung in der eingebetteten Software und Elektronik wobei diese Prozentzahl jedoch noch steigen wird da auch
133. der sei es aus finanziellen oder anderen Gr nden stehen die Benutzer meist vor dem Problem mit einer ver nderten Schnittstelle klar kommen zu m ssen Daraus k nnen Spannungen entstehen wenn eine Gew hnung an das neue Programm nicht eintritt oder sich nur sehr langsam entwickelt In dieser Arbeit wird auf die Grundlagen solcher Probleme eingegangen um dann die auftretenden Spannungen zu betrachten und L sungsm glichkeiten zu suchen und aufzuzeigen Ich werde in dieser Arbeit auch versuchen verst ndliche Beispiele zu bringen um die Problematik und ihre Konsequenzen zu verdeutlichen 1 Einleitung und Motivation 1 1 Motivation Wer von uns hat sich noch nie mit Software konfrontiert gesehen die ihm oder ihr einfach unverst ndlich zu sein schien Nicht dass diese Software explizit falsch oder fehlerhaft gewesen w re sie widersetzte sich einfach nur dem Verst ndnis und der Assoziation mit bisherigen Erfahrungen Wir sind nicht gewohnt derart h ufig eine Ver nderung der Benutzerschnittstelle zu erleben in anderen Bereichen des Lebens selbst in anderen Gebieten der Technik bleibt die Art und Weise wie sich Dinge ben tzen lassen ber einen lagen Zeitraum unver ndert Kaum jemand w rde beispielsweise eine Ver nderung in der Bedienbarkeit eines Autos so einfach hinnehmen wie eine Ver nderung einer Benutzerschnittstelle in der Computerwelt Eine derartige Belastung im Lernaufwand kann schnell zu Problemen und Ablehnu
134. die Gleichungen und die Datenelemente welche die Metriken beschrei ben zu spezifizieren So stellt z B die Vorberei tungsrate eine Funktion auf die Gesamtanzahl der in spizierten LOC die Vorbereitungszeit f r jede Inspek tion und die Anzahl der Inspektoren dar F r die Met rik wird ein Modell erstellt welches sie als Gleichung darstellt So wird etwa bei der Vorbereitungsrate zuerst die Vorbereitungszeit f r jede Inspektion durch die Anzahl der Inspektoren geteilt Danach wird die Summe ber alle Inspektionen gebildet und f r die Normalisierung der Gesamtcodel nge verwendet Auch wenn die Metriken durch Gleichungen oder Verh ltnisse beschrieben werden ist die Definition nicht immer klar und eindeutig Der GQM Plan liefert keine Aussage dar ber wie z B LOC zu messen sind sondern stellt nur fest dass irgendein Ma f r die Co degr e erforderlich ist Die Resultate der Datensammlungsphase f r 2 Pro jekte sind aus Tabelle 3 ersichtlich Tabelle 3 AT amp T Ergebnisse Metrik 1 Projekt 2 Projekt Anzahl der Inspekti 27 55 onen im Projekt Anzahl der KLOC 9 3 22 5 die inspiziert wurden LOC die inspiziert 343 409 wurden Vorbereitungsrate 194 LOC h 121 9 LOC h Inspektionsrate 172 LOC h 154 8 LOC h Anzahl an Fehlern 106 89 7 pro KLOC der Reinspektionen 11 0 5 Das Resultat f r AT amp T zeigte dass zu schnell durchgef hrte Inspektionen darin resultierten dass weniger Fehler gefunden wurden
135. diese einen gesamten Ausbau aus dem Systemumfeld mit sich ziehen w rden 2 1 Einsatzbereiche der Software Die wesentlichen Software Komponenten die in einem KFZ eingebaut sind lassen sich allgemein in sicherheitskritische und nicht sicherheitskritische Systeme einteilen Wobei das Versagen der ersten Einteilung Menschenleben fordern kann sind nicht sicherheitskritische Systeme mehr f r den Komfortbereich verantwortlich und strapazieren lediglich die Nerven des Autobesitzers Dadurch stellt sich die Frage welche Software im PKW unterst tzt uns Autofahrer und wird als unabdingbar angesehen und welche unterh lt und am siert uns nur Eine der wohl wichtigsten Erfindungen der letzten Jahre im Zusammenspiel mit Software war die des Airbags patentierte Erfindung der Firma Mercedes von 1968 69 Hier bernimmt die Software die Steuerung von eigens angefertigten Airbag Chips Diese Steuerung und berwachung ist bei weitem wichtiger als man annehmen k nnte denn die Aktivierung des Airbags darf nicht in allen Situationen erfolgen Bei einem Frontalaufprall misst die Software die Aufprallgeschwindigkeit und den Aufprallwinkel und errechnet in 10 bis 40 tausendsel Sekunden ob es sich dabei um eine lebensbedrohliche Kollision handel oder der Lenker nur einen kleinen Parkschaden verursacht hat Auch das ABS Anti Blockier System ist heute eine Grundausstattung im Automobil die nicht mehr wegzudenken ist Sensoren an jedem Rad mes
136. dlicher zu machen soll folgende Graphik beitragen MISRA C theoretische Automa QAC4 5 1 MISRA Automa tisierbarkeit tisierbarkeit 120 120 0 100 an iii 60 sch 40 40 ws 20 I Ih Requirded Asa Raquirded Advisory Die empfohlene und erzielte Automati Die theoretisch erreichbare und tats chlich sierbarkeit von Code erzielte Inspektionsqualit t mit QA C Inspektionen nach MISRA Standard Abbildung 4 Automatisierbarkeit 4 Daraus ist ersichtlich wie effektiv die Entwicklung dieses Tools war und welche Vorteile sich f r die Automobilhersteller zur Qualit tssicherung der eingebetteten Software ergeben Dennoch sind die von MISRA angebotenen Programmierstandards nicht nur von Nutzen Die urspr ngliche St rke der modularen Programmierung in C oder C n mlich die Portierbarkeit und Wiederverwendbarkeit hat dazu gef hrt dass sich die meisten Projekte vom urspr nglichen Designziel entfernt haben Das bernehmen von bestehenden Modulen das Hinzuf gen von Features was alles auch fast immer unter Zeitdruck geschieht kann eine Applikation bis zur totalen Un bersichtlichkeit wachsen lassen wo eigentlich eine berarbeitung des Designs n tig w re 23 Oft fehlt es auch den Entwicklern an Toleranz und durch fehlende berpr fung der gegebenen Metriken kann die Hilfestellung unbedeutend werden 5 Was bringt die Zukunft T r und Tor ffnen sich in der heutigen Zeit f r einfallsreiche E
137. ds tzlich die Vorteile eines Qualit tsmanagementsystems dargelegt da Qua lit tsorientierung ein Wettbewerbsvorteil f r moderne Unternehmen ist Wir sind der Meinung dass Auf wand und Kosten f r eine Zertifizierung nicht gescheut werden sollen da man dadurch das Vertrauen der Kunden und Lieferanten steigern und das Image des Unternehmens verbessern kann Eine Zertifizie rung alleine f hrt nicht zum Erfolg sondern Qualit t muss im Unternehmen von allen Beteiligten gelebt werden Die ISO 9000 besitzt diese grundlegenden Vorteile eines Qualit tsmanagementsystems und z hlt dar ber hinaus zu den bekanntesten Standards da es in der Wirtschaft h ufig verwendet wird In der neuen Versi on der ISO 9000 wurden viele Nachteile behoben sodass eine leichtere Anwendung f r alle Unterneh mensgr en und Branchen m glich ist Ist das Ziel eines Unternehmens TQM dann kann man sich mit einer ISO 9000 Zertifizierung diesem Ziel n hern da in der Langzeitrevision einige wichtige Prinzipien des TQM Konzepts umgesetzt wurden Auch in der Softwarebranche gelten alle Vorteile der ISO 9000 Zertifizierung Der Prozessverbesserung wurde in der Weiterentwicklung der Norm mehr Auf merksamkeit geschenkt trotzdem kann sie CMM als speziell entwickeltes Modell f r die Verbesserung des Softwareentwicklungsprozesses nicht ersetzen Die ISO 9000 Normfamilie ist eine gute Wahl f r Qualit tsmanagement und sie schlie t andere Modelle nicht aus
138. dung Dies beruht darauf dass sehr viel vorbereitende Arbeit durchgef hrt werden muss z B Trai ning des GQM Teams e Sch tzungsweise 50 des Aufwandes werden f r die Definierung des Messprogramms auf gewendet Im Vergleich dazu entfielen bei der Routine Anwendung nur 30 auf diesen Pos ten Vor allem die Erstellung des GQM Plans und des Messplans ben tigt hierbei mehr Auf wand e 70 des Aufwandes werden vom GQM Team und 30 vom Projektteam verwendet was keine Ver nderung zur Routine Anwendung darstellt e Der Aufwand des Projektteams ist weniger als 2 ihrer Gesamtarbeitszeit Dies ist doppelt so viel wie in der Routine Anwendung Der erh hte Aufwand f r die erstmalige Durchf h rung entsteht haupts chlich durch zus tzliche Trai nings und Lernzeiten Vor allem muss das GQM Team den Aufbau eines GQM Plans und dabei die Definition von Goals und daraus die Ableitung von Questions erlernen Nat rlich stellt die oben gezeigte Aufwandsvertei lung nur Richtwerte dar da einige Faktoren diese noch verschieben k nnen So erfordert etwa eine gr ere Anzahl von GQM Goals auch einen erh hten Auf wand bei allen Aktivit ten Auch die Vergr erung des Projektteams steigert den Aufwand f r die Ausbil dung und Datensammlung 3 2 Nutzen von GQM Der gr te Nutzen eines Messprogramms liegt dar in die klar definierten produkt oder prozessspezifi schen Verbesserungsziele zu erreichen Daneben k
139. e Grundvoraussetzung ist aber dass die Fehlerfindungs Effizienz fiir jede Testeinheit die Selbe ist Bei Verletzung dieser Annahme ist eine akkurate Prognose ber verbleibende Fehler nicht m glich Dies w rde die Kurve in Abbildung 3 mehr oder weniger konkav formen 120 159 3 Man kann keine Vergleiche ziehen zwischen unterschiedlichen Releases da die Erfolgsquote derselben Testfolge f r zuk nftige Releases weniger wahrscheinlich ist 4 3 1 Kompensierung bei Versto gegen ber Modell Annahmen Es gibt zumindest drei M glichkeiten darauf zu reagieren Verst e zu ignorieren Daten zu modifizieren oder neue Modelle abzuleiten Der erste Ansatz wird oft gew hlt da man eine gewisse Ungenauigkeit gerne in Kauf nimmt im Austausch f r Einfachheit Parameter Absch tzungen helfen dabei dessen Ausma e zu bestimmen Wenn Annahmen sehr starke Ungenauigkeiten verursachen besteht die M glichkeit der Adaptierung von Eingabe Werten Beispielsweise k nnen die Anzahl der gesamten Fehler wie Teststunden modifiziert werden Die bei weitem komplexeste M glichkeit ist ein f r sich geeigneteres Modell zu entwickeln das der Testumgebung mehr entspricht Der Vorteil dabei besonders bei Zustandsbasierten Modellen ist dass das Framework zur Zuverlassigkeits Prognose auch zur Performance Analyse benutzt werden kann 4 4 Praktische Umsetzung In den meisten F llen finden Modelle Einsatz die auf die jeweilige Test Umgebung
140. e Methoden Aufruf Assoziation ausl st 4 Effektives Testen mit ORDs Wie schon erw hnt ist ein Hauptproblem beim Testen objektorientierter Software eine geeignete Test reihenfolge f r die Klassen zu finden Eine geeignete Metrik f r eine Testreihenfolge stellen die ben tigen Stubs dar Ein Stub muss immer dann erzeugt werden wenn eine zu testende Klasse von ungetesteten Klassen abh ngt Stubs stellen die minimale Funktionalit t bereit die f r die Klasse im Test notwendig ist Sie sollten m glichts einfach gehalten sein und nur aus einer sequenziellen Ausf hrung bestehen um selbst keine Fehler zu enthalten 5 6 Au erdem muss man ber cksichtigen dass eine Klasse die von mehreren Klienten Klassen benutzt wird nicht nur durch einen Stub simuliert werden kann F r jede Klient Klasse muss ein eigener Stub geschrieben werden da jeder Stub nur ein spezifisches Verhalten f r eine Klasse bereitstellt Bei der Verwendung von ORDs zur Ermittlung einer Testreihenfolge ergibt sich das Problem von Zyklen Wenn ein Zyklus vorhanden ist m ssen Abh ngigkeitskanten gel scht werden um diesen aufzul sen F r jene Klasse auf welche die gel schte Kante gerichtet war muss in weiterer Folge ein Stub geschrieben werden Aus folgenden Gr nden ist es am sinnvollsten ausschlie lich Assoziationsbeziehungen zu l schen 4 e Aggregationsbeziehungen erfordern in der Regel mehrere Stubs wenn sie gel scht werden e Bei Vererbung
141. e Kommunikationsarten zu definieren Ein Standardlayout f r E Mails senkt die Hemmschwelle eine elektronische Kommunikation zu initiieren und hilft somit die L sung des jeweiligen Problems schneller und exakter zu ermitteln Jeder Projektteilnehmer muss wissen auf welche Art und Weise er mit einem Kollegen vom anderen Projektteam in Kontakt treten soll Nat rlich m ssen auch die zu erstellenden Dokumente ein Standardformat haben Dadurch kann der Abgleich und die Integration der an verschiedenen Orten erstellten Dokumente problemloser erfolgen Die Erstellung von UML Use Case Diagrammen von einem Team l sst sich nur schwer mit den nat rlich sprachlichen Dokumenten des anderen Teams abgleichen siehe Johnston Peters Schneider und Wellen 4 Diese Schwierigkeiten k nnen durch die rechtzeitige Definition von Standards vermieden werden 3 3 Tools F r verteilte Projekte bietet sich die Verwendung von Tools besonders an da dies eine M glichkeit ist eine Einheit zu schaffen die alle Teams gleicherma en betrifft Ein Requirements Engineering Tool zu verwenden ist auch eine einfache Methode gewisse Standards festzulegen Die Dokumente haben dadurch ein vorgegebenes einheitliches Layout Leider sind bisher noch keine Requirements Engineering Tools auf dem Markt die die besonderen Anforderungen eines globalen Projektes ber cksichtigen Zowghi 2 Eine Erleichterung des Dokumentenmanagement und auch der projektinternen Kommuni
142. e Wahrscheinlichkeit Fehler ans Licht zu bringen Es kommt aber vor dass einige wenige Einheiten Bereiche vom Code pr fen die selten benutzt werden Dabei ist die Wahrscheinlichkeit h her Fehler zu finden als normal Es gibt noch viele weitere Einschr nkungen die beachtet werden m ssen um ein Modell einwandfrei anwenden zu k nnen Dies ist jedoch von Modell zu Modell recht verschieden und muss problemabh ngig betrachtet werden 4 3 1 Effekte bei Verletzung der Annahmen Es k nnen folgende Effekte bei Nichteinhaltung verursacht werden 1 Der Parameter Alle Fehler steigt anstatt konstant zu bleiben Software Reliability Growth Models gehen davon aus dass die Fehlererkennungsrate abnimmt nachdem ja jeder Fehler sofort behoben wird und die Anzahl der verbleibenden Fehler immer geringer wird Da aber zus tzlich auch Fehler hinzukommen kann die Fehlererkennungsrate geringer sinken als angenommen Eine andere M glichkeit besteht darin dass weniger Fehler gefunden werden als prognostiziert Der Grund daf r kann darin liegen dass der Fehler erst nach dem Test eingebaut wurde Alle Fehler Anzahl Fehler Fehler Entdeckungskurve ohne Fehlerwachstum a Fehler Entdeckungskurve mit Fehlerwachstum Testzeit Abbildung 3 Fehler Entdeckungskurve 2 Fehler korrelieren nicht genau mit der Testzeit weil es zu manchen Zeiten wahrscheinlicher ist Fehler zu finden als zu anderen Zeiten Eine mathematisch
143. e ein spezieller Prozess abl uft Je h her man in den Stufen des Modells auf steigt desto besser sind die Prozesse erfasst und defi n ert 108 159 Wie aus Tabelle 1 ersichtlich werden mit steigen der Stufe und exakterer Definition der Prozesse mehr und mehr Sachverhalte erkennbar wobei genau jene erkannten Gegebenheiten f r einen Entwickler mess bar sind Nicht Sichtbares kann auch nicht gemessen werden Tabelle 1 Prozess maturity und Metriken 5 Maturity Charakteristiken Typen von Met level riken Optimi Verbesserungs Prozess mit Feed zing feedback f r den back zur nde Prozess rung Managed Gemessener Pro Prozess mit Feed Zess back zur Kontrol le Defined Prozess definiert Produkt und institutionali siert Repeatable Prozess von Indi Projektmanage viduen abh ngig ment Initial Adhoc Grundmetriken Wird das GQM Modell zur Planung eines Mess programms genutzt macht es also Sinn vor der Fest legung auf bestimmte Metriken die Maturity Stufe der Organisation zu identifizieren Das CMM Modell suggeriert wie oben bereits ausgef hrt dass nur sicht bare Sachverhalte gemessen werden k nnen Die Ver wendung von CMM in der GQM Definitionsphase zeigt also ein umfassenderes Bild davon welche Met riken am meisten Nutzen bringen GQM hilft uns also zu verstehen warum wir ein bestimmtes Attribut mes sen und CMM zeigt uns ob wir f hig sind es sinnvoll zu messen 3 3 Kosten und Nutzen v
144. e mittels Nachrichtenaustauschs miteinander wobei diese Objekte nicht in einer Hierarchie beziehung zueinander stehen spricht man von Kopplung Je h her der Nachrichtenfluss zwischen den Objekten desto undurchsichtiger werden Funktionalit t und Wirkungsweise der beteiligten Objekte Diese Interaktivit t erh ht die Kop plung im System und erschwert Modularit t Reuse und Er weiterbarkeit Insbesondere gibt die Kopplung Hinweise auf die Sensibilit t einer Einheit im Hinblick auf nderungen in anderen Teilen des Systems 2 2 Vererbung Je tiefer eine Klasse in der Vererbungshierarchie liegt desto mehr Methoden erbt diese Klasse und desto mehr ber schreibungen und berladungen der Methoden sind m glich nderungen in Superklassen f hren zu direkten nderungen in allen Subklassen Alle eventuellen Auswirkungen dieser nderungen m ssen beachtet werden um die Komplexit t des Systems bestimmen zu k nnen Ziel ist es eine ausgewo gene Vererbungshierarchie zu finden welche weder zu einer zu schwachen noch einer zu starken Vererbung tendiert 2 3 Koh sion Die Bindung Synonym Koh sion beschreibt den Grad der Zusammengeh rigkeit der zu einer Einheit zusammengefassten Elemente 14 Softwaresysteme die objektorientiert entwickelt werden sind in ihrer Gesamtheit als unabh ngige miteinander kommu nizierende Einheiten anzusehen Die Bildung der verschiede nen Einheiten sollte m glichst nachvollziehbar sein und klar
145. e wie zum Beispiel das Einf hren und Ausbilden junger Mitarbeiter die durch das Begutachten der Arbeit anderer einiges hinzulernen k nnen Verbesserung des Verst ndnisses des Projekts und die Erzwingung von Sorgfalt bei der Erstellung des Produkts Das Ziel eines Reviews ist es Fehler aufzudecken nicht sie zu beheben Das Ergebnis eines Reviews ist eine Diagnose die in einem Protokoll festgehalten wird Dieses gibt wieder welche Teile als gut befunden werden und nicht ge ndert werden d rfen und begr ndet welche mangelhaft sind und warum diese ge ndert werden m ssen 2 2 Abgrenzung zwischen Software Test und Review Reviews und Testen sind sich erg nzende Methoden Beide haben ihre St rken und beide sollten in der Softwareentwicklung zur Anwendung gelangen Ein Unterschied der Beiden Qualit tssicherungsma nahmen liegt darin dass die Formale Inspektion im Gegensatz zum Testen in jeder Phase des Softwareentwicklungsprozesses eingesetzt werden kann Daher Fehler fr hzeitig eliminiert werden wodurch das Auftreten von Folgefehler 20 159 vermieden wird w hrend das Testen der Softwarekomponenten erst dann m glich ist wenn die Entwicklung des Systems entsprechend weit fortgeschritten ist und zumindest ein Codefragment vorliegt Ein weiterer Unterschied liegt darin dass bei der Durchf hrung eines Reviews viele Fehler auf einmal aufgefunden werden k nnen Im Gegensatz dazu ist es bei der Durchf hrung eines Testes
146. ealisiert werden ein erhebli ches Ausma annehmen Sie sind dennoch meist eher gering Au erdem kann durch moderne Kommunikati onsformen zB E Mail Video und Telefonkonferen zen diesen Kosten teilweise entgegengewirkt werden Der Personalaufwand hingegen ist der wichtigste und gr te Kostenfaktor Aus diesem Grund wird der errechnete Aufwand des Projektes in der Regel in Per sonenmonaten angegeben Dies f hrt wiederum dazu dass die Aufwandssch tzung gemeinsam mit der Zeit planung erfolgt Bei den Personalkosten handelt es sich nicht nur um die Entlohnung der beteiligten Programmierer sondern auch andere Kosten werden in diesen Satz eingerechnet Dies sind unter anderem Kosten f r die Bereitstellung Beheizung und Be leuchtung der B ror ume Kosten f r unterst tzendes Personal zB Buchhal ter Sekret re Reinigungspersonal Kosten f r Netz und Kommunikation Kosten f r zentrale Einrichtungen zB Bibliothek Aufenthaltsraum Kaffeek che Kosten f r sozialen Aufwand zB Sozialversiche rung und Mitarbeiterzuwendungen zB Erfolgs beteiligung 1 2 Methoden Zur Aufwandssch tzung stehen nach Barry Boehm folgende Methoden zur Verf gung BOEH81 49 159 1 2 1 Algorithmische Modelle Algorithmische Mo delle bieten ein oder mehrere Berechnungsverfahren die eine Vielzahl an Einflussfaktoren ber cksichtigen Diese Berechnungsverfahren k nnen linear Fakto ren werden addiert m
147. ealit t mit Modellen anzun hern andererseits m ssen diese jedoch auch noch praktisch durchf hrbar sein um eingesetzt zu werden Im Folgenden seien einige Annahmen beispielhaft kurz angef hrt und erl utert Dass nicht jede Annahme f r jedes Modell gilt und es modellspezifisch noch viele weitere Einschr nkungen gibt liegt auf der Hand Fehler werden sofort berichtigt nachdem sie entdeckt wurden Dies hie e man m sste das Testen so lange auf Eis legen solange der Fehler nicht bereinigt wurde Normalerweise wird aber weiter getestet In der Realit t kommt es vor dass Fehler mitunter nicht sofort ausgemerzt werden k nnen Damit w rde das Modell von einer verzerrten Fehlerfindungseffizienz ausgehen und die Testzeit variieren Fehler werden anstandslos behoben Damit meint man dass sich keine zus tzlichen Fehler bei der Korrektur einschleichen Studien belegen Gegens tzliches Man geht davon aus dass zwischen jedem Sten bis 20ten Fehler der ausgebessert wird ein neuer Fehler produziert wird 1 Dieses Problem ist bekannt wird aber von den meisten Modellen ignoriert Es kommt zu keinem zus tzlichen Code w hrend der Test Periode Damit meint man einerseits keine zus tzlichen Features und andererseits keine Fehlerbereinigung Dass der letzte Punkt zum Widerspruch zum ersten steht sei ohne Zweifel Des Weiteren ist es in vielen F llen schlicht unm glich zus tzliche Funktionalit ten zu unterbinden Jede Testeinheit hat dieselb
148. eduziert wird und Kosten und Zeit gespart werden wenn Testen von Projektbeginn an als integra ler Bestandteil der Software Entwicklung geplant und umgesetzt wird 15 Alles in allem sieht man somit dass der Akzeptanz test selbst keine geringe Auswirkung auf die Qualit t des fertigen Produktes hat Denn was n tzt es wenn die Software gut wartbar und erweiterbar sehr zuver l ssig und sicher ist wenn ihr eine wichtige Funktion fehlt Oder zwar alles vorhanden ist allerdings so kompliziert zu bedienen ist dass man ohne Handbuch das Programm nicht einmal beenden geschweige denn berhaupt starten kann Au erdem verbessert es die Qualit t des Endpro duktes wenn ein Abnahmetest korrekt durchgef hrt 17 159 wird da dadurch Fehler entdeckt werden k nnen die sonst erst bei der endg ltigen Inbetriebnahme entdeckt werden w rden Dadurch wird Zeit und Geld gespart Und das sind meiner Meinung nach auch zwei wichti ge Faktoren die nicht au er Acht gelassen werden sollten 8 Konklusion Abschlie end kann man sagen Abnahmetests sind ein sehr wichtiges Thema vor allem auch f r Soft wareentwickler Denn wie schon eingangs erw hnt definiert der Abnahmetest den bergang zwischen Implementierungs und Wartungsphase 2 Au erdem sollte der Verk ufer dem K ufer Hilfe stellung in der Ausf hrung geben 11 10 und da w re es als Auftragnehmer gut zu wissen was zu tun ist oder wo man Informationen dar ber fi
149. egration und Infrastrukturprogrammie rung siehe Zielgruppen Die Sch tzung f r dieses Modell basiert auf der gleichen Grundformel wie das Early Design Model siehe Abbildung 4 und Abbildung 5 Da zu diesem sp teren Zeitpunkt nun schon mehrere Informationen zur Verf gung stehen werden statt den sieben Projekt und Prozessfaktoren nun 17 Einflussgr en oft auch Cost Driver genannt verwendet die durch diesen zus tzlichen Detailliertheitsgrad zu einem genaueren Ergebnis f hren sollen BOEH00 PM A Gr e M bzw PM A Gr e M PM m M II Cost Driver PM ASLOC AT 100 ATPROD Abbildung 5 Formel Post Architecture Model Die Einflussfaktoren sind vier verschiedenen Grup pen zugeteilt Produktattribute RELY Required Software Reliability die erfolgreiche Systemzuverl ssigkeit DATA Data Base Size die Gr e der verwendeten Datenbank CPLX Product Complexity die Komplexit t der Systemmodule RUSE Required Reusability der ben tigte Wiederverwendungsgrad DOCU Documentation match to LC needs der Umfang der erforderlichen Dokumentati on Computerattribute TIME Execution Time Constraint die Beschr nkung der Ausf hrungszeit STOR Main Storage Constraint die Speicherbeschr nkung PVOL Platform Volatility die Unbest ndigkeit der Entwicklungsplatt form Personalattribute ACAP Analyst Capability
150. eiben sondern auch zwischen den Herstellern und Zulieferer Angefangen von der 46 159 Anforderungsanalyse den einzelnen Entw rfen und der Implementierung bis hin zu den unterschiedlichen Tests muss die Kooperation und die Einarbeitung der Qualit t f r die Softwarekomponenten im Automobil und deren Sicherung auf einer gemeinsamen Basis erfolgen Nur durch st ndigen Kontakt gut funktionierendes Teamwork und gegenseitigen Wissensaustausch erh ht sich die Sicherheit der SW und gleichzeitig deren Qualit t da diese nicht allein in der Designphase oder alleine in der Testphase erreicht werden kann Durch enge Zusammenarbeit sowie deutlich festgelegte Schnittstellen und Verantwortlichkeitsbereiche wird es m glich in jeder Phase der Herstellung eine Qualit ts berpr fung entweder durch externe oder interne Fachleute durchzuf hren So l sst sich erkennen dass die Software Qualit tssicherung ein gro es Gebiet in der Automobilindustrie einnimmt und ein neues Denken von Entwicklern verlangt da diese sich nicht nur mehr auf ihre hardware im Auto versteifen d rfen Durch den hohen Prozentsatz der verwendeten Software ist es erforderlich alle Abteilungen der Unternehmen f r die Zusammenarbeit zu motivieren um das gesamte Gedankengut aller Beteiligten einflie en lassen zu k nnen Der hierbei entstehende Aufwand ist bei Weitem gerechtfertig wenn dadurch Menschenleben gerettet werden k nnen Zum Abschluss m chte ich no
151. eilnehmerzahl bei der eine rein elektronische Betreuung zu aufw ndig w re Individualkommunikation via e mail Andererseits schien bei den im Studium j n geren Bakkalaureatsstudierenden und auch aufgrund des Faktums dass es sich um eine Pflichtlehrveranstaltung handelte eine rein elektronische Abwicklung als zu riskanter Schritt 4 Ablauf Die Seminarordnung die diese Veranstaltungsform festlegte und der Call for Papers siehe Anhang 2 wur den bereits vor Lehrveranstaltungsbeginn ber das Con tent Managementsystem CLAROLINE f r die Zielgruppe publiziert und in der ersten Veranstaltung erl utert Hiezu ist zu bemerken dass das Programm nur bis zu Beginn der Osterferien genau spezifiziert wurde da bei der zu Lehrveranstaltungsbeginn vorliegenden Teil nehmerzahl die Abhaltung der Vortragsphase unrealis tisch hohen Zeitaufwand erfordert h tte die Lehrveran staltungsleitung allerdings davon ausgehen konnte dass sich die Teilnehmerzahl im Zuge des Begutachtungs prozesses wohl reduzieren w rde Das Ausma dieser Reduktion konnte freilich nicht antizipiert werden In ihrem tats chlich eingetretenen Umfang war dies sehr bedauerlich Auch war vorab nicht klar wie viel Studie rende das Angebot in ein anderes f r Diplomstudenten angebotenes Seminar zu wechseln annehmen w rden W hrend der beiden ersten Wochen wurden Themen vorschl ge der Studierenden erfragt und vom Lehrver anstaltungsleiter kommentiert Neben dem Z
152. ein der agilen Entwicklung beschrieben Die Hauptaufgabe der Qualit tssicherung ist daher nun das Testen Durch den Wegfall klassischer Analysephasen ist nun der Kunde dazu berufen die Rolle des Anforderungsanalysten sowie die Rolle des Testers teilweise auszu ben Der Kunde sowie der Entwickler erstellen nun Testf lle die das Produkt am Ende der einzelnen Iterationsphasen erf llen muss In diesem Zusammenhang spricht man hier von einer Testkrankheit der Entwickler da nun das Testen nicht mehr nur f r die Tester zum Aufgabengebiet z hlt sondern auch vermehrt zu dem des Entwicklers Die Art der Qualit tssicherung beziehungsweise des Testens ist aber von der verwendeten agilen Methode abh ngig Im Wesentlichen kann aber davon gesprochen werden dass die Testt tigkeit beim Einsatz von agilen Methoden nicht mehr als notwendiges bel angesehen wird sondern dass von einer testgetriebenen Softwareentwicklung gesprochen werden kann Diese fortw hrende Testgenerierung und ausf hrung soll nun dazu dienen die Kunden anforderungen zu berpr fen und zu erf llen Diese st ndige T tigkeit kann nur ausge bt werden wenn entsprechende Automatisierung vorgenommen werden kann Die Voraussetzung der Automatisierbarkeit der Tests ist ein wesentliches Kriterium f r die Entwick lung mit agilen Methoden Der Einsatz von automati sierten Testframeworks soll neben der leichten ber pr fung der Testf lle auch dazu dienen den Kunden ein Wer
153. einer Anforderung Post Traceability in der Literatur auch als Forward Traceability bekannt ge nannt wird wird das Traceability einer Anforderung zur ck zu seinem Ursprung Pre Traceability in der Literatur auch als Backward Traceability bekannt genannt 4 Die n chsten 2 Unterkapitel von Requirements Tra cing behandeln Pre Traceability und Post Traceability Bevor jedoch erklart wird wie diese 2 Arten des Re quirements Tracing von statten gehen gibt es vorweg noch eine kurze Erkl rung 1 Pre Traceability dazu werden Aspekte des t gli chen Lebens in die Requirements Specification RS der Produktion miteinbezogen Post Traceability hierbei flie en die Resultate die bei der Entwicklung eines Produktes entstehen post mortem in die RS ein Wie Eingangs schon notiert wurde ist der Ausgang bei Post und Pre Traceability immer von einer Requi rements Specification RS Diese RS muss sollte folgende 7 Qualit tsattribute aufweisen 13 70 159 Pre RS traceability Post R Traceability Abb 4 2 Typen des Requirements Tracing 1 Komplettheit Eine Anforderungsspezifikation sollte alle relevanten und bedeutenden Anforde rungen des Systems einschlie en functional dass sind jene die sich mit den Themen Funkti onen und Features besch ftigen und non functional das sind die die sich auf Perfor mance und Qualit t beziehen Konsistenz sprich die bereinst
154. eister die TUV Informationstechnik GmbH kurz TUVIT 14 und die Software Quality Systems AG kurz SQS 15 die ich in diesem Kapitel kurz vorstellen werde Zu den praktischen Beispielen geh rt auch ein Internetforum auf das ich bei meinen Inter netrecherchen gesto en bin das WIKI WIKI Web 12 Hier tauschen Menschen vor allem Software Entwickler aus aller Welt Informationen ber ihre Erfahrungen aus Und unter anderem gibt es hierbei auch eine Seite zum Thema Akzeptanztests die hier behandelt wird Den Abschluss meines Ausflugs in die Praxis macht die Homepage des Governments of British Columbia oder besser gesagt des Ministry for Sustainable Resource Management 5 das Richtlinien f r Abnahmetests herausgegeben hat Diese Richtli nien werde ich etwas genauer durchleuchten 6 1 T V Informationstechnik GmbH Die T V Informationstechnik GmbH kurz TUViT ist ein Unternehmen der RWTUV Gruppe und ging aus dem 1990 gegr ndeten Institut f r Infor mationstechnik hervor T VIT wurde 1996 eine ei genst ndige GmbH die die Durchf hrung von Reviews die Testplanung die Erstellung der Test spezifikation die Testfallbeschreibung die Testdurch f hrung sowie den Aufbau wiederholbarer auf Wunsch auch automatisierter Regressions und Abnahmetests anbietet und dazu erfahrene Testexper ten oder ein komplettes Team inklusive Testmanager zur Verf gung stellt F r T VIT besteht der Abnah metest allerdings nur aus einer
155. eit nicht nur auf die neuwertigen Entwicklungen richten sondern vor allem auch auf die Sicherung der Qualit t dieser neuen Software 6 Res mee Der Anteil der im Automobil verwendeten Software wird insofern in den n chsten Jahren enorm anwachsen mit ihm die Notwendigkeit die korrekte Funktionsweise die Verl sslichkeit und die Qualit t mitzusichern Dieses Gebiet der Informatik hat demnach eine gro e Zukunft und einen ebenso gro en Bedarf an Experten die sich diesem Thema widmen Heutzutage verlassen sich die Hersteller in der Automobilindustrie nicht mehr nur auf die Kollegen der Informatik sondern erstreben selbst die Kontrolle der Software im PKW zu erlangen Ein Beispiel daf r ist BMW das vor einiger Zeit eigens ein Tochterunternehmen BMW CAR IT gr ndete um die Qualit t der eingebetteten selbst hergestellten Software zu steuern und zu kontrollieren um eine eigene Qualit tspolitik betreiben zu k nnen Daraus entstehen eine Vielzahl von Regeln Verfahren und Vorschriften zus tzlich zu denen die durch MISRA vorgegeben werden und erlauben es so der Qualit tssicherung sich auf die berwachung des Entstehungsprozesses der Software zu konzentrieren Die Software Qualit tssicherung liegt jedoch nicht nur in der Hand der Entwickler Um die Sicherheit zu gew hrleisten ist es besonders notwendig bei dem Entstehungsprozess die Zusammenarbeit nicht nur zwischen den Programmierern und Herstellern vertiefend zu betr
156. ekts werden geplant und dokumentiert e Die beteiligten Personen und Gruppen vereinbaren ihre Kompetenzen in Bezug auf das Softwareprojekt Die Aktivit ten des Prozessbereichs Softwareprojektlenkung und Verfolgung erm glichen einen Einblick in die Aktivit ten und den Status eines Projekts Weiterhin erm glichen sie die Projektaktivit ten zu berwachen und Lenkungsma nahmen zu ergreifen Sie nutzen den Softwareentwicklungsplan des Projekts als Basis f r berwachung und Lenkung Das Software Unterauftragnehmermanagement befasst sich mit der Auswahl und dem Management von Komponentenlieferanten f r das Softwareprojekt Die Softwarequalit tssicherung sorgt daf r dass das Projekt seinem Prozess treu bleibt und verschafft dem Management Einblick in den Prozess Sie signalisiert dem Management wenn die Lenkungsma nahmen der Softwareprojektlenkung und Verfolgung unzureichend sind Das Software Konfigurationsmanagement bezieht sich auf die Lenkung sowohl des Produkts das zur Lieferung bestimmt ist als auch der Zwischenprodukte die im Laufe des Projekts entstehen 2 3 Um den n chsten Reifegrad zu erreichen ist die Griindung einer Prozessgruppe und die Einfiihrung einer Software Entwicklungsprozess Architektur SEA notwendig Die Aufgabe der Prozessgruppe ist es Verbesserungen am Softwareprozess vorzunehmen Sie erstellt periodisch Reviews tiber den Projektstatus und fortschritt und identifiziert neue f r
157. em in Bereichen wie Tele kommunikation Luft und Raumfahrt Automo bilindustrie sowie im Finanzsektor ben tigt wird Auf unterster Ebene findet man die Programmie rung der Infrastruktur Typische Bereiche sind bei spielsweise Betriebssysteme Datenbankmanagement systeme Benutzerschnittstellenmanagementsysteme und Netzwerksysteme Bekannte Firmen auf diesem Sektor sind Microsoft Netscape Oracle Sybase 3Com und Novell BOEH00 Early Design 13 parameters Relative 2 Size Range Post Architecture 23 parameters Applications Composition 3 parameters Concept of Operation Feasibility Plans Product Detail Devel Phases and Milestones Abbildung 2 COCOMO II Modellphasen BOEH00 2 3 Das Modell COCOMO II ist im Grunde genommen nicht nur ein einzelnes Modell Je h her die Entwicklungsstufe und das Fortschreiten des Projektes umso genauer kann auch die Absch tzung erfolgen siehe Abbil dung 2 Daher besteht COCOMO II aus drei Teilmo dellen die sich bez glich Skalenfaktoren Aufwands multiplikatoren und Modellkonstanten unterscheiden Hier ein kurzer berblick 1 The Application Composition Model Die fr he Prototypenstufe Die erste grobe Gr ensch tzung basiert auf der Methode der Object Points und erfolgt mit einer einfachen Gr en Produktivit tsformel 2 The Early Design Model Die fr he Entwurfsstufe In dieser Stufe sind bereits alle Systemanforde rungen
158. en Thresholds are heuristic values used to set ranges of desirable and undesirable metric values for measured software These thresholds are used to identify anomalies which may or may not be an actual problem 15 Das hei t wenn f r eine Metrik ein solcher Grenzwerteffekt identifiziert w re dann k nnten Klassen mit Werten die un terhalb dieses Grenzwertes liegen als sicherer Bereich ange sehen werden und Programmierer die ihre Klassen bewusst auf diesen Bereich beschr nken h tten Gewissheit dass in diesen Klassen kaum Probleme bzw Fehler auftreten Ein solcher Grenzwert wird in Abbildung 1 3 auf der rechten Seite dargestellt Da f r die meisten Metriken jedoch kein solcher Grenzwert bekannt ist wurden Grenzwerte aufgrund von empirischen Wissen also Erfahrung festgelegt wie etwa in 15 Hierbei wird bei einem gewissen Wert eine Grenz linie gezogen und Klassen deren Werte ber diesem Grenz wert liegen werden die sein die am meisten Probleme bzw Fehler aufweisen Somit k nnen solche Grenzwerte zwar f r die Identifizierung der fehleranf lligsten Klassen verwendet werden jedoch k nnen Klassen mit Werten unterhalb dieses Grenzwertes trotzdem eine hohe Fehlerrate aufweisen je doch nicht die h chste Ein solcher Grenzwert wird in Ab bildung 1 3 auf der linken Seite dargestellt Nat rlich w ren erstere Grenzwerte f r Programmierer von gr erem Vorteil als Letztere aber im allgemeinen scheint es schwier
159. en Auf zeichnungen ber die Art des Jobs und dessen tats ch licher Dauer die erwartete Zeit f r die jetzt f llige Aufgabe genauer sch tzen als ohne eine solche Auf zeichnung Am Ende wird die Sch tzung an der tat s chlichen Dauer der Aufgabe gemessen die ebenfalls im Time Recording Log siehe Abbildung 5 2 notiert wird rele m Te Tees Tee Dosorihen Vite program OOO ro Tee eo wo 1 ee oes wo wy Desotlion Read earo Chapter O Description Read textbook Chay Abb 5 5 Produktplan auf Basis des Time Recording Logbuchs Zum besseren Verst ndnis der Abbildung 5 5 er folgt eine kurze Erl uterung der Jobs 2 und 6 Job 2 Zum Lesen des Textes nahm man sich eine Zeitspanne von 50 Minuten vor Tats chlich ben tigte man f r zwei Kapitel 80 Minuten das sind 40 Minuten pro Kapitel Statistisch gesehen verbrachte man bisher 80 Minuten mit Lesen Das sind je Kapitel durch schnittlich maximal und minimal 40 Minuten Job 6 Man rechnete mit 60 Minuten zum Lesen ei nes Kapitels Tats chlich ben tigte man 118 Minuten Damit brauchte man bisher f r 4 Kapitel 226 Minuten was eine Durchschnittszeit von 56 5 Minuten ergibt Die n chste Sch tzung f r Job 9 basiert auf diesem Mittelwert Je mehr Daten bez glich einer Aufgabenart vorhan den sind desto genauer wird die Prognose in Zukunft ausfallen Kritisieren m chten wir an diesem Ansatz trotzdem dass es f r Unge bte h ufi
160. en Informationen zu erleichtern soll in dieser Arbeit nicht verschwiegen werden dass ihr Einsatz in der Praxis nicht unumstritten ist Zwei der Kritikpunkte an Metriken werden in den folgenden Unterkapiteln n her erl utert 5 1 Validierung Die Zahl der vorgeschlagenen OO Metriken ist jetzt schon kaum berblickbar und nat rlich ist davon auszugehen dass auch weiterhin neue Metriken hinzukommen Bei der raschen Weiterentwicklung kommt die Validierung oft zu kurz Vor allem bei ganz neuen Ans tzen w re ein Validierung wichtig um zu sehen ob der neue Weg sinnvoll ist So konnte etwa Robert Martins OO Design Quality Metrik nicht validiert werden obwohl sie zun chst durchaus plausibel erscheinen mag und einige interessante neue Ideen enth lt Auch bei Varianten bereits bekannter Metriken w re es notwendig zu berpr fen ob durch die nderung auch tats chlich eine Verbesserung gegeben ist Ein Versuch einige OO Metrik zu vergleichen wurde an der University of Alabama durchgef hrt 3 Dabei wurden mehrere Koh sionsmetriken an zwei C Klassenbibliotheken errechnet Zwei Expertenteams bewerteten evenfalls diese Klassen hinsichtlich Koh sion Die h chste Korrelation zur Meinung der beiden Teams wurde bei der LCC Metrik festgestellt Bei LCOM und seinen Varianten wurde keine eindeutige Reihenfolge ersichtlich Am schlechtesten schnitt TCC ab Das Ergebnis f llt zwar recht eindeutig zu gunsten von LCC aus dennoch
161. en Mutanten erkannt werden Die restlichen Mutanten m ssen noch von Hand identifiziert werden 10 Offutt Kwnon und Ma haben vor kurzem ein Tool mit dem Namen pJava entwickelt pJava erstellt aufgrund von 24 auf objektorientierte Fehler basierenden Operatoren objektorientierte Mutanten f r Javaklassen Nach der Erstellung der Mutanten k nnen die Tests durchgef hrt und die Testmenge berpr ft werden Die Mutanten werden automatisch erstellt und ausgef hrt quivalente Mutanten m ssen jedoch per Hand identifiziert werden 11 Aufgrund dieser Schwachstelle ist dieses Tool f r den praktischen Einsatz wohl noch nicht interessant genug Man kann trotzdem behaupten dass aufgrund der neuen Konzepte und der spezifischen Mutationsoperatoren ein Tool f r Java das sich f r den praktischen Einsatz eignet in greifbare N he ger ckt ist Es wird spannend sein zu beobachten wie die Entwicklung auf diesem Gebiet voranschreitet 5 Schlussfolgerung Zwei Faktoren werden unserer Meinung nach dazu beitragen dass die Rolle von Mutationentests in Zukunft an Bedeutung gewinnen wird Ein Faktor ist die Tatsache dass Software vermehrt in Anwendungen die hohe Verl sslichkeit fordern wie Life Critical Systems und _ E Business Systems verwendet wird 1 Der zweite Faktor sind die Fortschritte die im Bereich des Mutationentests selbst erzielt werden konnten Der n chste Schritt wird die Entwicklung eines Tools sein das hohe Automation bietet
162. en ber cksichtigen Um diese Forderungen zu verwirklichen wurde ein 2 Phasen Modell f r die Revision entwickelt Phase I Kurzzeitrevision Phase II Langzeitrevision vgl Sch 01 S 21 98 159 Im den n chsten Abschnitten wird auf den Inhalt der zwei Revisionen genauer eingegangen 2 6 Kurzzeitrevision ISO 9000 1994 In der Kurzzeitrevision blieb die urspr ngliche Struktur erhalten Das Ziel war die Behebung der Un klarheiten Neudefinition von Begriffen und die Festlegung der Dokumentenanforderungen Die Bedeutung des Begriffes Produkt wurde da hingehend erweitert dass er nicht nur Hardware sondern auch Software Dienstleistungen oder Kombi nationen daraus einschlie t vgl ISO194 S 6 Au erdem wurden die Begriffe Lieferant Ein k ufer und Kunde klarer voneinander abgegrenzt da diese nicht immer einheitlich verwendet wurden und dadurch sehr verwirrend waren Weiters wurde der Kundenzufriedenheit mehr Aufmerksamkeit ge schenkt vgl ISO494 S 8 2 7 Langzeitrevision ISO 9000 2000 Die Gr nde f r die notwendige Revision wurden im Abschnitt 2 6 dargelegt Aufbauend auf die nde rungen der Kurzzeitrevision wurden in der Langzeitrevision gro e Ver nderungen betreffend Struktur und Inhalt vollzogen Au erdem versuchte man eine bessere Umsetzung des Total Quality Man agement Gedankens zu erreichen Auf den Vergleich zwischen ISO 9000 und dem Total Quality Manage ment kurz TQM
163. en die 9 Ei genschaften des Meta Modells verstanden enthalten sein sollten da es die verschiedensten Stakeholder in der Entwicklung eines Systems unterst tzt Solche Systeme die essentielle F higkeiten eines Systement wicklungsprozesses erfassen k nnen sind notwendige Komponenten f r einen sinnvollen Einsatz von Tra ceability Schemata 4 2 Wer zieht Nutzen aus dem Traceability Modell Nachdem nun verdeutlicht wurde welche Eigen schaften solche Modelle besitzen sollten um den SEP 73 159 zu erleichtern m chte ich nun kurz auf die Personen eingehen die am SEP arbeiten und die Nutzen aus dem Modell ziehen k nnen Eine Studie von WST fokus siert am Gebrauch von Requirements Traceability kam zum Schluss dass folgende Parteien im Softwareent wicklungsprozess Nutzen aus einem Traceability Modell ziehen k nnen 14 4 2 1 Top Management Das Top Management von WST sieht den Gebrauch von Requirements Traceability als ein Muss f r das berleben bereinstimmend kam das Mana gement zur Aussage dass Anforderungen keine Wahl sind sie sind notwendig und dass es wichtig sei den Kunden gl cklich zu machen Traceability stellen Kundenzufriedenheit sicher indem wir ihm dokumen tierte Mittel zur Verf gung stellen durch die der Kun de berpr fen kann ob alle angegebenen Anforderun gen entsprechen und er somit sieht dass der Job kom plett ist 4 2 2 Projekt Management Das Projektmanagement glaubt das
164. en immensen Lernaufwand auf die Verwaltung all der Masken und Codes ist f r Anf nger sehr verwirrend Da ein intuitives Verst ndnis des Programms nicht gegeben ist bedeutet dies dass ein gro er Lernaufwand bei der bernahme des Systems zu bew ltigen ist Dokumentationen und Schulungen sind hier unverzichtbar Die Firma SAP ist sich dessen bewusst und bietet umfangreiche Schulungen an die Aufgrund der M chtigkeit des Programms auch von vielen genutzt werden Im Vergleich zwischen Linux und Windows zeigt sich welche Unterschiede Benutzerschnittstellen aufweisen k nnen Diese Unterschiede beruhen auf verschiedenen Weltbildern und wirken sich in allen Aspekten aus Linux bietet die Freiheit zu w hlen es handelt sich hier grunds tzlich um ein Kommandobasiertes Betriebssystem das beliebig mit einer Graphischen Oberfl che erweitert werden kann Windows bietet hingegen die Freiheit nicht w hlen zu m ssen und folglich ist hier alles standardisiert und leicht verst ndlich Die Auswirkung auf die Interaktion beim Benutzen ist enorm und ein Wechsel zwischen diesen beiden Betriebssystemen stellt eine gro e Umstellung dar 8 WIMP Interfaces haben ihren Ursprung in den sechziger Jahren des letzten Jahrhunderts bei einem Mann namens Douglas Englebart und dem Human Augmentation Project bei SRI die Abk rzung WIMP steht f r Windows Icons Menus und Pointing device Mit der Entwicklung der ersten Prototypen der heute allseits benut
165. en sich wegen Methoden Aufrufketten durch das Programm fort So eine Aufrufkette entsteht wenn z B Klasse A eine Methode von Klasse B aufruft welche wiederum die Methode einer anderen Klasse aufruft und so weiter Kung et al haben die L nge der Aufrufketten f r die InterView C Grafikbibliothek mit 220 Klassen mehr als 400 Klassen Abh ngigkeiten und insgesamt ber 1000 Methoden ermittelt siehe Abbildung 1 Es ist ersichtlich dass die meissten Aufrufketten eine L nge zwischen 2 und 7 besitzen auf das Aufrufketten o 1 2 83 4 5 6 7 8 9 10 11 12 13 14 Lange der Aufrufkette Abb 1 Aufrufketten der Interview Library 3 Objekt Relations Diagramme ORDs wurden urspriinglich von Kung et al entwickelt Ein ORD ist ein gerichteter Graph bei dem die Knoten Klassen darstellen und die Kanten Abh ngigkeiten Je nach Abh ngigkeitstyp werden die Kanten mit f r Vererbung As f r Assoziation und Ag f r Aggregation beschriftet Der Graph kann zyklisch sein lelass Parent public void meth 2 class Child extends Parent public void meth 3 class Assoc Parent par 5 public Assoc Parent par 6 this par par Tog 8 public void assocMeth 9 this par meth 10 11 public static void main 12 Child c new Child 18 Assoc a new Assoc c 14 a assocMeth Abb 4 Programmbeispiel Die urspr nglichen ORDs nach Kung 2 ber cksichtigen nur statische Abh ngigkeiten
166. endem Sourcecode das bei Software Bin r Bausteinen gegeben ist vorgestellt 2 Komponentenbasierte Software Moderne Softwaresysteme werden immer umfang reicher und komplexer was zu hohen Entwicklungs kosten geringer Produktivit t und Problemen mit der Software Qualit t f hrt Ein vielversprechender L sungsansatz ist daf r die komponentenbasierte Soft wareentwicklung Component Based Softwareengi neering CBSE Component 1 Component 2 Component n Commercial Off the shelf COTS components Abbildung 1 Komponentenbasierte Software Entwicklung 3 Component i Softwar repository Software system N assemb le j select Die Idee ist dabei passende Off The Shelf Komponenten auszuw hlen und diese anhand einer klaren Software Architektur zu einem Software System zusammenzusetzen siehe Abbildung 1 Diese Komponenten k nnen von unterschiedlichen Entwick lern kommen unter Verwendung verschiedenster Pro 128 159 grammiersprachen implementiert sein sie k nnen auf unterschiedlichen Plattformen und als verteiltes Sys tem ausgef hrt werden 3 Diese Heterogenit t bringt Probleme mit sich wenn komponentenbasierte Soft ware mit traditionellen Methoden getestet werden soll Wenn der Sourcecode einer Komponenten nicht verf gbar ist kann ein White Box Test normalerweise nicht angewandt werden Falls der Sourcecode doch vorliegt k nnen Probleme dadurch auftreten dass die Komponente
167. enscheinlich In einigen F llen las sen Indizien auf das strikte Einhalten der Vertraulich keit schlie en Dies bedeutet freilich dass das Begutachtungsverfah ren seitens der Lehrveranstaltungsleitung auch tat s chlich mit Ernst und Sorgfalt eines Begutachtungs verfahrens f r eine echte Konferenz durchzuf hren ist Review Formulare Es wurden echte Begutach tungsformulare verwendet nur minimale Adap tionen Dies erh ht die Glaubw rdigkeit und war bei Spezialseminaren durchaus ad quat F r zu viele hier eingereichte bersichtsarbeiten war dies jedoch nicht ganz passend Ich w rde daher wenigstens f r die Begutachtung der Extended Abstracts im Wiederholungsfall speziell auf diesen Lehrveranstaltungstyp zugeschnittene Review Formulare einsetzen f r die Endausarbeitung scheinen echte Formulare durchaus passend Format und Seitenvorgaben Beides hat sich m E bew hrt Das Limit mit 6 Seiten f r Zweierteams und 10 Seiten f r Bakkalaureatsarbeiten w rde ich beibehalten Jenes von 4 Seiten f r Einzelvortragende scheint zwar fair zu sein ist aus meiner Sicht jedoch etwas problematisch Auch h hersemestrigen Studie renden fehlt offenbar noch die Routine auf so engem Raum ein Thema in gebotener Tiefe darzustellen Es bleibt jedoch den Leserinnen und Lesern dieses Readers berlassen sich dar ber ein eigenes Urteil zu bilden Zeitplan Der Zeitplan war durch die berbelegung zu Beginn der Veranstaltung ei
168. entation Die Dokumentation ist bedingt durch die Planung und Analyse ein zentrales Qualit tssiche rungsmittel des traditionellen Ansatzes In allen Mo dellen findet sich auch Testen als Qualit tssiche rungsma nahmen wieder meist als eigene Phase in nerhalb des Prozesses Testen wird als Mittel zur Tes terkennung eingesetzt und kommt meist nach der Im plementierungsphase zur Anwendung Dokumentation hingegen ist das Mittel das einge setzt wird um Fehler zu vermeiden Dies bedingt na t rlich eine genaue und umfangreiche Dokumentation Voraussetzung ist dass sich die Entwickler an diese Dokumentation halten und ber diese Dokumentation untereinander kommunizieren Gerade diese Vorge hensweise erm glicht es den Prozess zu standardisie ren und tr gt hiermit wiederum einen Teil zur Quali t tssicherung bei Dokumentation erh lt diese wichtige Aufgabe dadurch dass durch die Dokumentation alle Anforderungen alle Schritte festgehalten werden und das an hand der Dokumentation der Reviewingprozess betrieben wird Hinsichtlich der Probleme ist gerade durch die Ori entierung nach Phasen und nach dem Prozess zu bemerken dass je fr her ein Fehler erkannt wird desto billiger ist es diesen zu beheben Werden nun die ge n derten Kundenanforderungen als Fehler betrachtet Fehler hinsichtlich der Analysephase so sind nde rungen je sp ter sie bekannt werden umso teurer Software ist in den letzten Jahren wie bereits erw hnt d
169. ents kennen zu lernen Ziel dieser Arbeit ist es den Leser zu motivieren Zeit managementpraktiken in der Schule und im Beruf in der Softwareentwicklung einzusetzen Marina Glatz 0060330 mglatz edu uni klu ac at 2 Der individuelle Softwareentwicklungs prozess 2 1 Definition Unter dem individuellen Softwareentwicklungspro zess versteht man die Abfolge der Arbeitsschritte die ein Individuum bei der Entwicklung von Software sei es nun alleine oder als Mitglied in einem Team in einem Unternehmen an einer Universit t oder an einer Schule in einer gewissen Zeit in einem gewissen fi nanziellen Rahmen und mit einer gewissen Qualit t erbringen muss Die T tigkeiten eines Entwicklers eines Ent wicklungsteams umfassen hierbei die Planung des Pro jekts aufgrund der Anforderungen eines Auftraggebers das Design die Implementierung die bersetzung und den Test der Software Die einzelnen Schritte werden dokumentiert und bilden die Basis f r den an schlie enden Post Mortem Prozess 1 in dem R ck schl sse auf die Arbeitsweise durch eine Analyse des realen Zeitaufwandes und der aufgetretenen Fehler raten gezogen werden k nnen 2 2 Bedeutung des Individuums im Software entwicklungsprozess Jede Software ist nur so gut wie der schlechteste Mitarbeiter Besonders bei gr eren kostspieligen Pro jekten die im Team bearbeitet werden sind die Anfor derungen an den Einzelnen hoch Ein Entwickler sollte deshalb in
170. er Alternativ werden oft Tester durch Belohnung stimuliert ein kriminelles Verhalten an den Tag zu legen Weiters k nnen nicht nur freiwillige Benutzer am Projekt beteiligt werden sondern auch unwissende oder unfreiwillige Unerkannte Beobachtung kann in der Anforderungsanalyse n tzlich sein und Testobjekte m ssen nicht immer wissen dass sie gestestet werden siehe Sicherheitssysteme 5 Partizipation die ber Anforderungsanalyse und Test hinausgeht zielt in zwei Richtungen Zum einen wird die Erf llung der Erwartungen noch sicherer gestellt Wenn Kunde und Benutzer in den gesamten Prozess eingebunden sind ist eine Fehlinterpretation der Anforderungen sehr unwahrscheinlich und die Benutzer werden mehr oder weniger exakt das Produkt bekommen das sie gewollt haben Aber zum anderen hat eine derart enge Einbeziehung auch eine andere Wirkung Nicht nur die Benutzer pr gen dadurch das System sondern auch das System die Benutzer 13 Erstens hat eine derart enge Teilnahme eine sehr gute Lernwirkung Eine sp tere Notwendigkeit des vertraut Machens f llt weg Und zweitens sind Mitarbeiter die in die Entwicklung des Systems eingebunden wurden zur Loyalit t dem Programm gegen ber verpflichtet da sie es selbst entwickelt haben Wer ist schon bereit seine eigene Leistung herabzusetzen So kann sichergestellt werden dass Benutzer ein Programm sp ter auch akzeptieren selbst wenn es noch Fehler enth lt Ver nderungsmanagement ist e
171. er Systemgrenzen Beschreibung des bisherigen Systems Festlegen der Schl sselzile und Aufgaben Identifikation der Schw chen des bisherigen Systems Analyse der Arbeitszufriedenheit Analyse zuk nftiger Entwicklungen Spezifikation und Reihung von Effizienz und Arbeitszufriedenheitsanforderungen organisatorisches Design Technische Aspekte Vorbereitung eines detaillierten Arbeitsdesigns Implementierung Evaluierung 10 4 L sungen Richtlinien und Standards haben sowohl f r die Entwickler als auch f r die Benutzer ihren Nutzen Sie stellen dem Entwickler bew hrtes Wissen zur Verf gung und geben ihm somit Sicherheiten und ersparen ihm unter Umst nden das Rad neu zu erfinden Die kollektive Erfahrung aller Entwickler flie t in diese Richtlinien und Standards ein und so ist der einzelne Entwickler in der Lage auf das Wissen aller zuzugreifen Aber dar ber hinaus haben diese Richtlinien und Standards noch eine weitere auf den zweiten Blick sehr vorteilhafte Eigenschaft Ihre eiserne Einhaltung engt den Entwickler ein und beraubt ihn vieler M glichkeiten Dies geht auf Kosten der Kreativit t und neue Ideen und Innovationen k nnen schwerer umgesetzt werden Aus der Sicht der meisten Entwickler eine unangenehme Sache sie k nnen sich nicht mehr v llig einbringen und f hlen sich unter Umst nden eingeengt Aber f r die Benutzer hat diese Eigenschaft einen immensen Nutzen durch die eingeschr nkte Handlungsfreiheit der
172. er noch nicht alle Korrekturen erledigt sind wird nicht zur n chsten Phase weitergegangen 3 2 Inspektionsteam An der Inspektion nehmen mehrere Personen teil Die richtige Anzahl der Teilnehmer ist wichtig f r die Effizienz einer Inspektion Zu viele Teilnehmer erh hen zwar den Aufwand bringen aber nur geringf gig mehr Nutzen Idealerweise sollte die Gruppe aus mindestens 3 aber h chstens 6 Personen bestehen Nun stellt sich noch die Frage welche Rollen diese Personen bernehmen e Der Moderator Er ist f r die Planung den Ablauf die Organisation und die Durchf hrung der Inspektion verantwortlich Er hat insbesondere daf r zu sorgen dass die Sitzungen effizient und in geordneten Bahnen stattfinden Er ist sowohl f r die Auswahl der Teilnehmer als auch f r die Bereitstellung der ben tigten Informationen und Unterlagen die aus Sourcecode Dokumentationen Produkt Dokumenten Anforderungsanalysen Spezifikationen Header Files Regeln und Checklisten bestehen zust ndig e Der Autor ist der Urheber des zu inspizierenden Objektes oder ein Repr sentant des Teams das den Pr fling erstellt hat Er hat die Aufgabe auftretende Fragen zu kl ren und Hintergrundinformationen bereitzustellen allerdings ist es ihm nicht erlaubt aktiv an der Inspektion teilzunehmen oder gar L sungen vorzuschlagen oder zu rechtfertigen Weiters f llt ihm das sp tere Korrigieren der bei der Inspektion aufgedeckten Fehler zu e Der Gutachter
173. er Aufwandsunterschied zwischen 2h und Bakk Seminarteilnehmern in Relation zum Stun denumfang In diese Kategorie geh rt wohl auch die unter dar ber hinaus m chte ich zu dieser Lehrver anstaltung noch festhalten getroffene Kritik zu harte Beurteilung vor allem der Bakkalaureatsstudierenden Dort findet sich auch die Bemerkung dass bei Kurz pr sentationen nicht klar war was pr sentiert werden 149 159 soll Dies ist richtig gab es doch lediglich formale Vorschriften Zeitdauer Folienanzahl Doch gerade das dadurch entstandene Spektrum bot Diskussionsstoff und zeigte auch dass durchaus unterschiedliche Strategien sehr positive Effekte erzielen k nnen Auch die Bemerkung Ziel bzw Thema musste selbst definiert werden daher lang auf dem Holzweg mag f r mehr als nur eine Person gegolten haben wurde jedoch nur von einer negativ vermerkt Bei all den anderen dom inierte offenbar die Motivation sich durch ein selbst gew hltes Thema durchzubei en Insgesamt und dies ergab wohl auch die abschlie Bende Diskussion mit den Studierenden wurde die Ver anstaltung trotz einer f r eine reale Konferenz erforder lichen rigiden F hrung mehrheitlich positiv beurteilt 6 Zusammenfassung Insgesamt darf festgestellt werden dass die Form der Abhaltung des Bakkalaureatsseminars als Konferenzsemi nar erfolgreich war Auch wenn in der Abschlussdiskus sion die Meinung vertreten wurde die Abfassung einer Bakkalaureatsarbeit im Sti
174. er Modelle wird an die Konstruktion des Produktes herangegangen Umgelegt auf den Softwareprozess bedeutet dies dass der Softwarepro zess aus Phasen besteht in denen bestimmte Methoden verwendet werden um das Ziel funktionierende Software zu erreichen Ein Phasenablauf k nnte wie folgt aussehen am Anfang steht eine Kundenanforde rung gefolgt von einer Planungs und Designphase nach der Annahme durch den Kunden folgt schlie lich die Entwicklungsphase 4 1 Traditionelle Softwareentwicklung Wie bereits erw hnt spielt Planung beim traditio nellen Ansatz eine gro e Rolle Die Planung beschreibt also das Vorgehen innerhalb eines Softwareprojektes mit gewissen Randbedingungen Wesentliche Bedeutung kommt hierbei auf die Wahl des Vor gehensmodells mit dem die Art der Softwareentwick lung bestimmt wird zu Dieses Vorgehensmodell strukturiert die Softwareentwicklung in Phasen wobei bei diesem Ansatz getreu den Anleihen aus den In genieurswissenschaften jede Phase zuerst abge schlossen werden muss bevor die n chste Phase be 31 159 gonnen werden kann Durch dieses Vorgehen soll gew hrleistet werden dass der Prozess berschaubar planbar und vergleichbar wird Dieses Vorgehen be dingt aber auch dass keine nderungen im Verlauf des Prozesses mehr auftreten In der Realit t k nnen solche nderungen nicht ausgeschlossen werden daher ist auch hier ein gro er Nachteil des traditio nellen Ansatzes zu fi
175. er Mutationsoperator simuliert den typischen Fehler dass ungewollt auf eine falsche namensgleiche Instanzvariable zugegriffen wird 9 Dazu wird in einer Subklasse die namensgleiche Instanz gel scht 6 IHI Hiding variable insertion Mit der selben Absicht wie beim IHD f hrt THI neue berschreibende Variablen ein Diese k nnen nur von Testf llen erkannt werden die falsche Referenzen auf berschreibende Variablen erkennen 6 bzw es muss zumindest einmal auf die entsprechende Variable zugegriffen werden da dieser Fehler sonst unentdeckt bleibt 9 140 159 IOD Overriding method deletion Um den Aufruf der richtigen Methode in der Subklasse sicherzustellen wird die berschreibende Methode der Subklasse entfernt und dadurch die Methode der Elternklasse ausgef hrt 6 Kann diese nderung nicht erkannt werden ist die Testmenge nicht ad quat oder die berschreibende Methode hatte die gleiche Funktionalit t 9 IOP Overridden method calling position change Manchmal ist es notwendig die Methode der Superklasse in der Methode der Subklasse die sie berschreibt aufzurufen Dies kann dazu f hren dass der Aufruf unbeabsichtigt zum falschen Zeitpunkt erfolgt IOP simuliert diesen Fehler durch das Vertauschen der Reihenfolge der Anweisungen 6 IOR Overridden method rename IOR dient zur berpr fung von Abh ngigkeiten berschriebener Methoden die zu unerw nschten Nebeneffekten f hren k nnen Zum Beispiel
176. er Requirements Engineering Prozess eines globalen Projektes ist ein Gebiet auf dem noch viel zu forschen ist Es m ssen Requirements Engineering Methoden entwickelt werden die auf all diese neuen Herausforderungen eingehen 5 Zusammenfassung Die Requirements Engineering Phase in globalen Projekten ist ein u erst spannendes und aktuelles Thema In dieser Phase treten viele Probleme die es bei globalen Projekten gibt besonders hervor andere kommen hinzu Die Probleme wurden in dieser Arbeit aufgelistet Die Schwierigkeiten liegen zum gro en Teil in der Erschwernis der Kommunikation Deshalb nimmt das Kapitel Kommunikationsbarrieren einen so gro en Platz in dieser Arbeit ein Es wird auf die Probleme der Sprachkenntnisse der Fremdheit synchroner und asynchroner Kommunikation eingegangen Des weiteren werden die Probleme Wissensmanagement Zeitverschiebung und der Kulturunterschiede angesprochen In diesem Dokument wurden auch einige L sungsm glichkeiten aufgezeigt Die von Dutoit Johnstone und Bruegge erw hnten Knowledge Scouts sind ein wichtiger Schritt da sie die soziale Komponente ber cksichtigen die in der Requirements Engineering Phase eine wichtige Rolle spielt Eine weitere Hilfe ist die Definition von Standards da in globalen Projekten ein gr erer Teil des Informationsaustausches ber Dokumente erfolgen muss als bei lokalen Projekten Ein einheitliches Layout beschleunigt die intellektuelle Verarbeitung und
177. er Sektion vom K ufer allein bestimmt werden mit nur einer kleinen oder gar keinen Rolle des Verk ufers aber genauso auch umgekehrt F r die Beschreibung der n chsten Punkte nehmen wir an dass K ufer und Verk ufer sich die Verantwor tung teilen Der springende Punkt ist allerdings dass der Verk ufer sicherstellen muss dass der Akzeptanz testplan des K ufers wirklich das Produkt testet und dass Probleme die w hrend des Planes auftauchen wirklich am Produkt liegen und nicht an einem schlechten Akzeptanztest 3 2 1 Zeitplan Jede Aktivit t ben tigt einen Zeitplan so dass Ressourcen verf gbar gemacht und verwandte Aktivit ten synchronisiert werden k nnen Je weiter weg vom vollst ndigen Prozess ein Plan kreiert wird und Abnahmetests sind so weit weg wie man nur kommen kann umso ungenauer wird der Plan sein Deswegen m ssen K ufer und Verk ufer zusammen arbeiten um den Zeitplan f r den Akzeptanztest aufzu 11 159 stellen und ihn entsprechend berichtigen wenn die Realit t den Entwicklungsplan st rt Der Startpunkt und die Dauer sind Sch tzungen und sollten daher mit einer gewissen Flexibilit t betrachtet werden 3 2 2 Evaluierungsvorgang Der Verk ufer muss mit dem K ufer zusammenarbeiten um sicherzustellen dass der K ufer genug Verst ndnis f r das Produkt hat um den Abnahmetest durchzuf hren Beide sollten darin bereinstimmen dass die entworfenen Prozedu ren auch ein legitimer Test des P
178. er das Schl sselwort vorkommt Der aktuelle Typ kann diese Klasse oder eine ihrer Subklassen sein this wird auch beim expliziten Aufruf eines Konstruktors der Superklasse als erste Anweisung im Konstruktor der Subklasse verwendet 8 3 2 Mutationsoperatoren f r Java Die im Folgenden erw hnten Mutationsoperatoren st tzen sich prim r auf den Artikel InterClass Mutation Operators for Java 6 Diese Aufz hlung ist nicht umfassend jedoch beinhaltet sie wichtige Mutationsoperatoren f r h ufige Programmierfehler die im Zusammenhang mit den vorhergehend erw hnten objektorientierten Sprachmerkmalen stehen Kapselung AMC Access modifier change Dieser Operator ndert die Zugriffsmodifikatoren public private und protected in deren Alternativen 6 Dadurch soll der korrekte Zugriff sichergestellt und dem Paradigma der Kapselung entsprochen werden 9 Dieser Fehler wird erkannt wenn durch die nderung Zugriffsrechte eingeschr nkt werden bzw Namenskonflikte entstehen 6 Vererbung Vererbung hat unter anderem den Vorteil der realit tsnahen Abbildung der bestehenden Welt Der Leistungsf higkeit dieses Sprachkonstrukts steht jedoch die gro e Gefahr der Un berschaubarkeit und daraus resultierender unerw nschter Nebeneffekte 7 und deren Fernwirkungen bei Wartungsarbeiten gegeniiber 7 Die folgenden Mutationsoperatoren sollen diese unerw nschten Fehlerquellen aufzeigen IHD Hiding variable deletion Dies
179. er sind Dell Nokia Microsoft Intel und General Electric 2 6 Kritische Betrachtung Durch die vielen Einflussfaktoren die ber cksich tigt werden m ssen wird die praktische Anwendbar keit von COCOMO etwas komplex Da diese Einfluss faktoren die urspr ngliche Sch tzung sehr stark beein flussen k nnen so k nnen hohe Werte zu einer drei mal so hohen Sch tzung f hren niedrige Werte zu 56 159 einem Drittel der urspr nglichen Sch tzung ist eine sorgf ltige Bewertung umso wichtiger Weiters wird kritisiert dass das Ziel dass Anwen der dieses Modells ihre eigenen Erfahrungen ber ck sichtigen und die Attributwerte auf ihren historischen Projektdaten basieren nicht erreicht wird da in der Regel zu wenige oder gar keine dieser Daten vorhan den sind Hier k nnte man entgegnen dass COCOMO f r den Beginn Standardwerte vorgibt die erfahrungs gem gute Ergebnisse liefern Erg nzend und zur Verfeinerung k nnen dann ber den Zeitverlauf ge wonnene Erfahrungen mitber cksichtigt werden SOMMOI berdies gelten f r COCOMO nat rlich auch die allgemeinen Kritikpunkte an algorithmischen Sch tz verfahren siehe Kapitel 1 2 Abschlie end ist an dieser Stelle anzumerken dass keine Methode frei von Kritik ist und COCOMO ge gen ber den anderen Verfahren viele Vorteile bietet 3 Res mee Zusammenfassend soll hier noch einmal verdeut licht werden wie wichtig Aufwandssch tzung f r je des Proje
180. erden diese Metriken vorgestellt 3 1 Weighted Methods per Class WMC DEFINITION 1 Gegeben sei eine Klasse C mit Methoden M Mn welche in der Klasse C definiert sind Seien C1 Cn die Komplexit t der Methoden Dann gilt i 1 WMC ist somit die Summe der Komplexit ten aller Me thoden M der Klasse C Sind die Komplexit ten der Me thoden ident dann gilt WMC n quivalent zur Anzahl der Methoden der Klasse Die Anzahl und Komplexit t der Methoden beeinflussen wieviel Zeit und Aufwand ben tigt werden um eine Klasse zu entwickeln und zu warten Je gr er die Anzahl der Methoden desto gr er ist ein m glicher Einfluss auf Sub klassen da Subklassen alle Methoden der Superklasse erben Klassen mit einer gro en Anzahl an Methoden sind meist anwendungsspezifisch und daher nicht besonders f r Reuse geeignet 3 2 Depth of Inheritance Tree DIT DEFINITION 2 Die Metrik gibt die Tiefe der Klasse C von der Wurzel des Vererbungsbaumes an Bei Mehrfach vererbung gibt die Metrik die mazimale Tiefe im Baum an Je tiefer eine Klasse in der Hierarchie steht umso gr er ist die Wahrscheinlichkeit dass diese Klasse eine gr ere An zahl an Methoden erbt wodurch ihr Verhalten schwieriger vorauszusehen ist Gro e Komplexit t im Design f hrt zu einem tieferen Vererbungsbaum da viel mehr Methoden und Klassen beteiligt sind Die Wahrscheinlichkeit dass eine ererbte Methode einer Superklasse verwendet wird ist in
181. erden kann oder nicht 6 2 By Hand Testing So genannte By Hand Tests werden dazu ver wendet um die Funktionalit t von graphischen Ein gabemasken zu testen Diese Art von Tests soll vor allem m gliche Eingabefolgen von Kunden hingehend auf Richtigkeit und Stabilit t berpr fen Hierzu wer den typische Eingabefolgen von Kunden ausgef hrt diese Eingabefolgen werden aufgezeichnet und dann mittels Skript durchgef hrt Da diese Art von Tests sehr zeitaufwendig ist wird sie nur auf Eingaben an gewandt die im sp teren Einsatzumfeld der Software h ufig Anwendung finden Au erdem k nnen diese Tests erst relativ sp t durchgef hrt werden da die wesentlichen darunter liegenden Funktionalit ten vor handen sein m ssen By Hand Tests werden vor allem bei klassischen Internetprojekten verwendet da hier die Eingaben und die dementsprechenden Funkti onen erfolgskritischer als bei anderen Projekten zu be trachten sind 6 3 Unit Tests Im Gegensatz zu den vorangegangenen Testarten werden Unit Tests von den jeweiligen Entwicklern durchgef hrt Wie im Kapitel ber XP bereits erw hnt werden Unit Tests vor Beginn der Entwicklung defi niert um so das erwartende Verhalten der Software im Vorfeld festzulegen Um einen Unit Test erfolgreich abzuschlie en m ssen alle Erfordernisse erf llt wer den das hei t im Gegensatz zum Akzeptanztest ist der Erfolg von der definierten Funktionalit t abh ngig und nicht von der ausf
182. ere Prozessschritte hat welche Personen davon betroffen sind und von wem sie bewilligt werden muss 5 4 2 Stufe 2 Repeatable Auf Stufe 2 gibt es strukturierte Anforderungen an den Prozess l Der Prozess untersteht einer Prozessdisziplin so dass erfolgreiche Projekte in Bezug auf Kosten Zeitplan und Anforderungen die Norm darstellen Projektleiter sind in der Lage angemessene Sch tzungen und Projektpl ne zu realisieren Anhand dieser Pl ne k nnen sie die Projektdurchf hrung verfolgen und lenken 2 Organisationen der Stufe 2 n tzen Erfahrungswerte aus abgeschlossenen Projekten und k nnen hnliche Softwareprozesse effizient durchf hren Sie haben jedoch Umstellungsprobleme wenn sie mit g nzlich neuen Prozessen konfrontiert werden 5 Stufe 2 sind folgende SPBs zugeordnet Das Anforderungsmanagement und damit die Lenkung der Anforderungen stellen einen entscheidenden Faktor bei der Stabilisierung des Softwareprozesses von Stufe 1 dar Nur ein stabiler Prozess macht Erfolge wiederholbar nicht gelenkte Anforderungen f hren zu versp teten Produktlieferungen und schlechter Qualit t Die Softwareprojektplanung geht auf eine Reihe von Problemen bei Softwareprojekten ein Ziele dieses SPB sind e Softwaresch tzungen in Bezug auf Umfang Zeitplan Aufwand etc werden dokumentiert um sie f r die Planung und Verfolgung des Softwareprojekts zu nutzen 91 159 e Die Aktivit ten und Kompetenzen des Softwareproj
183. erenden die teils Bakkalaureanten teils norma le Seminarteilnehmer waren allen eine angemessene Be treuung zuteil werden zu lassen Diese Veranstaltungs form stellt aber auch spezifische Anforderungen an Studierende was sich in einer hohen Zahl von Abbr chen zeigte Dieser Beitrag erl utert die Form der Abwicklung und fasst jene Ergebnisse zusammen die nicht unmittelbar aus den einzelnen Beitr gen der Studierenden erkennbar sind 1 Einleitung Das Universit tsstudiengesetz sieht vor dass Bakka laureatsarbeiten in Lehrveranstaltungen Mehrzahl zu erbringen sind Die Studienkommission Informatik der Universit t Klagenfurt hat als solche e das Seminar aus Angewandter Informatik und e das Praktikum aus Angewandter Informatik vorgesehen Weiters f hrt der Studienplan aus dass Bak kalaureatsarbeiten sich je nach Lehrveranstaltungstyp in ihrem formalen Aufbau an einer wissenschaftlichen Publikation bzw einem Projektbericht zu orientieren haben Dieser Bericht bezieht sich auf das Seminar In dieser Lehrveranstaltung ist daher laut Studienplan eine theore tisch konzeptionelle Arbeit die ein Thema entsprechend dem Stand der Wissenschaft bzw Technik aufarbeitet zu verfassen Da ich im Sommersemester des Jahres 2004 die Erstauflage eines solchen Bakkalaureats Seminars leite te es aber Prinzip ist die Seminarleitung zwischen In formatikprofessoren rotieren zu lassen und dar ber hinaus auch universit tsweites Interes
184. erleichtert das Auffinden von Differenzen in verschiedenen Dokumenten Die Verwendung von Groupware Tools ist f r verteilte Projekte unabdingbar da sie f r eine Vernetzung sorgt und teilweise auch Kommunikationsstrukturen vorgibt Sie bieten die technische Kommunikationsm glichkeit die in globalen Projekten gebraucht werden sowie einen gemeinsamen Platz f r den Dokumentenaustausch Diese L sungsans tze k nnen jedoch nur der Anfang sein Viele Probleme sind noch offen Die Requirements Engineering Phase in globalen Projekten bietet noch ein weites Forschungsfeld auf dem hoffentlich bald weitere Erkenntnisse gefunden werden 6 References 1 Allen H Dutoit Joyce Johnstone Bernd Bruegge Knowledge scouts Reducing communication barriers in a distributed software development project 8th Asia Pacific Software Engineering Conference APSEC 2001 Macau China Dec 2001 2 Zowghi Didar Does Global Software Development Need a Different Requirements Engineering Process International Workshop on Global Software DevelopmentOrlando Florida May 21 2002 3 Led Vera Kritische Erfolgsfaktoren in den Front End Lifecycle Phasen Diplomarbeit 1999 4 Johnston L Peters D Schneider J Wellen U Requirements Analysis in Distributed Software Engineering Education An Experience Report 6th Australian Workshop on Requirements Engineering AWRE 2001 Sydney November 2001 5 Damian Daniela
185. erpr fen Da im Laufe einer Software Inspektion das zu entwickelnde System nicht ausgef hrt werden muss wird diese auch als statische Validierungs und Verifikations Methode bezeichnet Diese Review Technik weist eine hohe hnlichkeit zum Technischen Review auf Der Ablauf von Inspektionen ist allerdings formaler und erlaubt dadurch den direkten Vergleich zu Normen und Standards Aufgrund des hohen Formalismus und relativ geringer Freiheitsgrade bei der Durchf hrung von Inspektionen ist diese Methode auch f r Schulungszwecke innerhalb des Projektteams gut einsetzbar da sowohl der prim re Nutzen von Inspektionen die Fehlerfindung als auch das Kennen lernen des Produkts und der Methode unterst tzt wird Inspektionen werden nach genau vordefinierten Schritten durchgef hrt Dabei sind sowohl die jeweiligen Phasen als auch die zu ermittelnden Messdaten als auch die jeweiligen Rollen genau vordefiniert Inspektionen weisen bez glich Prozessablauf und der Teilnehmerzahl einen h heren Detaillierungsgrad auf Diese Aufteilung kann jedoch ebenfalls f r Reviews eingesetzt werden Bei Inspektionen wird ein Softwaredokument z B Anforderungen Konzepte Szenarien Design Code von einem oder mehreren Inspektoren auf Fehler oder M ngel hin untersucht Software Inspektionen k nnen in jeder Phase des Softwareentwicklungszyklusses eingesetzt werden Im Vergleich zu dynamischen Verfahren wie zum Beispiel dem Testen k nnen Inspektio
186. erten Anforderungen stets den Entwicklern beziehungsweise dem Projektteam mit Dadurch ergibt sich aber auch der Rahmen in dem agile Softwareentwicklung betrieben werden kann 12 13 Die Kommunikation unter den Entwicklern erfordert es dass die Teamgr e beschr nkt ist zu gro e Teams erzeugen einen Overhead an Kommunikation Dies schl gt sich auf die Projekt gr e nieder agile Softwareentwicklung kann nur bis 32 159 zu einer gewissen Projektgr e betrieben werden Diese Einschr nkung ergibt sich auch durch die an gewandten Praktiken wie zum Beispiel Refactoring oder durch den inkrementellen Entwicklungsansatz Agile Softwareentwicklung erzeugt Software die kaum oder schwer wieder verwendbar ist durch die starke Bindung an die Kundeanforderung und der kaum vorhandenen Planungsphase werden Einzell sungen produziert Zudem wird angenommen dass eine Neuentwicklung wesentlich g nstiger ist als eine Weiterentwicklung Nachstehende Tabelle soll einige Unterschiede nochmals verdeutlichen agile SE traditionelle SE Beispiele Scrum FDD XP V Modell Spi ralmodell Ziel minimale Kosten bei maximaler Kundenzu friedenheit und maximaler Qualit t Strategie nderung so einfach wie Fehler m glich beziehungsweise nderungen ver meiden Mittel evolution res inkremen Dokumentation telles Vorgehen und Pr fung Prozess gestaltbar teamorientiert zertifizierbar planbar wieder holbar Tabel
187. es Ver halten wird durch Ver nderung der Einga ben Ausgabe Beziehungen erreicht Dieser Ansatz untersucht die Robustheit des Gesamtsystems Die 130 159 Kosten die durch Erh hung der Robustheit entste hen m ssen im Verh ltnis zu den Kosten f r die Komponenten stehen e Operational System Testing Dabei handelt es sich um einen erweiterten Systemtest wodurch die Re liability eines Gesamtsystems mit eingebauten COTS Komponenten abgesch tzt werden soll Mit einer Vielzahl an zuf lligen Samples wird das Sys tem getestet Ein Nachteil ist eben diese gro e Sample Menge die n tig ist um gute Sch tzungen machen zu k nnen Dies kann teuer und zeitauf wendig sein White Box Testen Devanbu und Stubblebine 5 entwickelten einen Ansatz f r das White Box Testen mit hohem berdeckungsgrad mit R cksichtnahme auf den Schutz geistigen Eigentums Sie schlagen vor den Test von einem Dritten durchf hren zu lassen dem der Verk ufer und der Kunde vertrauen Die Grundvarian te dieses Ansatzes sich wie folgt aus 1 Der Verk ufer V sendet dem Dritten D den Sourecode S in Verbindung mit der Testsuite und einer Beschreibung des gew nschten berde ckungsgrades 2 D generiert ein Binary aus S und konstruiert die berdeckungsmenge 3 D testet das Binary mit der Testsuite und berpr ft ob die berdeckungsmenge mit der Testsuite ber einstimmt 4 D teilt dem Kunden K mit dass ein bestimmter Uberdeckungsg
188. etriken zur Komplexit tmessung setzen auf der Arbeit von McCabe auf Cyclomatic Complexity wird auf Basis des Kontrollflu graphen 2 2 eines Moduls errechnet und gibt die Zahl der linear unabh ngigen Ausf hrungspfade an Ist E die Anzahl der Kanten edges und N die 4In englischer Literatur auch bekannt als program complexity oder als McCabe s Complexity in deutscher Literatur auch einfach McCabe s zyklomatische Zahl 59 159 Anzahl der Knoten nodes eines Graphen G dann errechnet man die Cyclomatic Complexity CC mit der Formel l CC G E N 1 Dieser ganzzahlige Wert erm glicht es Programmkomplexit t zu vergleichen im Allgemeinen besser als mit LOC und l t auf Verst ndlichkeit und Testbarkeit des Programmes schlie en 10 Bei objektorientierten Programmen l t sich CC auf die einzelnen Methoden anwenden Wie das konkret funktionieren kann wird in Kapitel 3 2 erkl rt CC ist auch in einigen der sp ter beschriebenen Werkzeugen implementiert 15 16 18 2 3 Halstead Complexity Measures Einen anderen Zugang zur Komplexit tsmessung fand Maurice Halstead Er untersucht mit seinen Metriken die Komplexit t auf Basis der Gesamtzahl der Operatoren N und Operanden N sowie der Zahl der unterschiedlichen Operatoren n und Operanden na in einem Modul Aus diesen Werten berechnet er die Programml nge N N Na das Vokabular n n na das Volumen V N x LOGan die Schwierigke
189. eziehungsweise das Handbuch wird bei XP erst bei Beendigung des Projektes den Kunden bergeben dies mag vielleicht viele Kunden davon abhalten sich auf Projekte mit XP einzulassen da die Software zuvor schon lange in Verwendung ist beziehungsweise getestet wird 6 Qualit tssicherung bei agiler Software entwicklung In den vorangegangen Kapitel wurde bereits sehr viel ber Qualit tssicherung gesprochen Dieses Kapitel soll die wesentlichen Punkte der Qualit tssicherung bei agiler Softwareentwicklung behandeln und auf die Testarten bei der Anwendung von agilen Methoden eingehen Durch die Umorientierung des Prozesses von Do kumentation und definierten Tests und Reviewing phasen hin zu einem inkrementellen Ansatz erfolgt hinsichtlich der allgemeinen Qualit tssicherung eine St rkung der Tests In der agilen Softwareentwicklung werden Dokumente als den Prozess behindernd ange sehen dies bedeutet aber nicht dass keine Dokumen tation stattfindet Rahmendokumente sowie zum Bei spiel das Handbuch werden weiterhin erstellt beziehungsweise m ssen weiterhin erstellt werden Die Abkehr von der Dokumentation hin zu der wesentlichen Arbeit des Programmierers l sst auch 35 159 erahnen dass agile Softwareentwicklung von diesen auch betrieben und forciert wird Im Zusammenhang der agilen Softwareentwicklung insbesondere in der Literatur wird gerade die Abkehr von der Dokumentation hin zur Kommunikation und Tests als der Meilenst
190. f hrt wird kann man sagen dass somit auch die Benutzer freundlichkeit getestet wird Test auf Benutzerakzep tanz denn wenn das Programm un bersichtlich und schwer zu bedienen ist wird es von den Endbenutzern wohl nicht akzeptiert werden Zur Effizienz finden wir eine Aussage in der Defi nition am Anfang von Kapitel 1 Denn dort hei t es der Abnahmetest testet Leistung Funktion Effizienz Performance und Konformit t Auf Wartbarkeit Erweiterbarkeit und bertragbar keit kann der Abnahmetest selbst keinen direkten Ein fluss nehmen da diese eher f r den Entwickler selbst relevant sind 16 Au er die Software soll in ver schiedenen Umgebungen eingesetzt werden denn dann f hrt man einen Feldtest durch siehe Kapitel 2 3 und testet somit auch einen gewissen Grad der bertrag barkeit Ansonsten gibt es Metriken wie etwa MISRA f r die Automobilindustrie n here Informationen http www misra org uk um diese Merkmale zu testen und so die Qualit t der Software anzuheben Was nun Zuverl ssigkeit und Sicherheit betrifft so sind diese zwei Eigenschaften Gegenstand des Systemstests 3 und wurden somit in der Stufe vor dem Abnahmetest schon getestet Der Aufwand f r fachliche Tests und Abnahmetests kann zwischen 10 und 30 des Projektaufwandes betragen Er steigt mit wachsender Komplexit t des Projektes 3 Deshalb ist Testen sehr wichtig Denn die Erfahrungen zeigen dass das Risiko eines Fehl schlages r
191. ferenzieren Dadurch stellt dieser Operator den richtigen Gebrauch von Zustandsvariablen sicher 6 JSC static modifier change Andert den static Modifikator von Klassenvariablen zu Instanzvariablen oder umgekehrt Dies erm glicht das Verhalten von Instanz bzw Klassenvariablen festzustellen 6 JID Member variable initialization deletion Grunds tzlich k nnen in Java die Instanzvariablen sowohl in der Variablendeklaration als auch im Konstruktor initialisiert werden Um deren korrekte 1 In 9 als AOC bezeichnet Initialisierung zu berpr fen l scht der Mutationsoperator JID deren Instanzierung in der Variablendeklaration 6 Oiginal Code JID Mutant Class Stack Class Stack int size 100 A int size Stack Stack Figure 4 JID 6 JDC Java supported default constructor create Entfernt implementierte Default Konstruktoren um deren korrekte Implementierung zu eruieren 6 4 Praktischer Einsatz Tools Obwohl Mutationentests schon seit den 1970ern bekannt sind werden sie au erhalb des akademischen Bereichs sehr selten verwendet Daf r gibt es mehrere Gr nde Offutt und Untch identifizieren in 1 unter anderem folgende das Fehlen wirtschaftlicher Anreize zur Verwendung strenger Testmethoden das Unverm gen Uhnit Tests erfolgreich in den Softwareentwicklungsprozess einzubinden und Schwierigkeiten eine automatisierte Technologie zur Unterst tzung von Mutatio
192. finition einiger Begriffe wurden verschie denste Ans tze zu diesem Thema vorgestellt Das Re pository Design zielt auf inhouse entwickelte Kompo nenten ab bzw auf die Kenntnis des Quellcodes Das Maturity Model und der Ansatz zur Automatisierung holen weiter aus und beeinflussen nicht nur den Be reich des Testens Hintergrund ist aber auch hier die Steigerung der Softwarequalit t Das effektive Testen ohne Kenntnis des Quellcodes ist eine gro e Heraus forderung im CBSE Dass auch Whitebox Testen durch die Einschaltung eines Dritten m glich ist ist ein vielversprechender Ansatz zur Entwicklung quali tativ hochwertiger Software 6 Referenzen 1 Y Wu D Pan and M Chen Testing Component Based Software Department of Information and Software Engi neering George Mason University Fairfax 2000 2 J Gao Testing Component based Software Problems Testability and Maturity Proceedings of Star 99 SQE 1999 3 X Cai M R Lyu K F Wong Component Based Software Engineering Technologies Development Frame works and Quality Assurance Schemes Asian Pacific Soft ware Engineering Conference APSEC 2000 Singapore December 2000 4 E J Weyuker Testing component based software A cautionary tale IEEE Software September October 1998 5 P T Devanbu S G Stubblebine Cryptographic Verification of Test Coverage Claims IEEE Transactions on Software Engineering Vol 26 No
193. fnahmef higkeit der Sinne Das Auge kann nur auf einem kleinen fokussierten Bereich klar sehen und in der Peripherie des Blickfelds sinkt die Sch rfe und damit steigt die Empf nglichkeit f r Bewegungen Auf einer h heren Ebene der Wahrnehmung spielt Vertrautheit eine Rolle und wir verstehen leichter Dinge die uns bereits bekannt sind So tendieren auch viele Entwickler von Software dazu aufgrund ihrer eigenen Vertrautheit mit der Benutzerschnittstelle diese als intuitiv zu betrachten Doch intuitiv sind Signale immer nur f r bestimmte Benutzergruppen beispielsweise ist der Entwurf von international verst ndlichen Verkehrszeichen sehr schwer Ein Beispiel f r unterschiedliche intuitive Wahrnehmung ist die Assoziation von Farben in Japan hier gilt Wei als die Farbe der Trauer und des Todes und in unterschiedliche Regionen Afrikas steht Rot f r Leben und in anderen f r Trauer Weiters zu erw hnen ist der Unterschied zwischen Orient und Okzident in der Frage ob Schriften und folglich auch Benutzerschnittstellen ihren Ursprungspunkt auf der rechten oder auf der linken Seite haben Wenn ein Benutzer mit einem System interagiert so tut er dies immer aufgrund eines Gedankenmodells Zus tzlich zur allgemein bekannten Rolle der unmittelbar sichtbaren Komponenten bildet er sich ein Modell des Verhaltens der f r ihn unsichtbaren Komponenten Ist dieses Modell nun fehlerhaft und stimmt nicht mit der Realit t berein so kann der Benut
194. ftware Reliability Engineering ISSRE 97 IEEE November 1997 pp 126 2 Chin Yu Huang Sy Yen Kuo Michael R Lyu Optimal Software Release Policy Based on Cost and Reliability with Testing Efficiency Twenty Third Annual International Computer Software and Applications Conference IEEE October 1999 pp 468 3 Mayuram S Krishnan Software Release Management A Business Perspective CASCON 94 IEEE 1994 4 Ganesh J Pai A Survey of Software Reliability Models Department of ECE University of Virginia December 2002 5 Rong Huei Hou Sy Yen Kuo Yi Ping Chang Optimal Release Times for Software Systems with Scheduled Delivery Time Based on the HGDM IEEE Computer Society IEEE February 1997 pp 216 221 6 Chin Yu Huang Jung Hua Lo Sy Yen Kuo Michael R Lyu Software Reliability Modeling and Cost Estimation Incorporating Testing Effort and Efficiency 10th International Symposium on Software Reliability Engineering IEEE November 1999 pp 62 7 Chin Yu Huang Sy Yen Kuo Ing Yi Chen Analysis of a Software Reliability Growth Model with Logistic Testing Effort Function Eighth International Symposium on Software Reliability Engineering ISSRE 97 IEEE November 1997 pp 378 8 Chin Yu Huang Sy Yen Kuo Ing Yi Chen Pragmatic Study of Parametric Decomposition Models for Estimating Software Reliability Growth The Ninth International Symposium on Software Reliabil
195. ftwarequalit t sondern steigern auch die Produktivit t von Softwareprojekten Eine ganz spezielle Variante des Reviews ist die Formale Inspektion deren Hauptqualit ten eine erhebliche Steigerung der Zuverl ssigkeit der Verwendbarkeit und die Reduktion der Wartungskosten eines Softwareproduktes sind 1 Einleitung Mit der zunehmenden Verbreitung von Computern und Mikroprozessoren und steigender Komplexit t der Produkte stiegen die quantitativen und qualitativen Anforderungen an Software wobei die Prozesse um diese Software zu erzeugen immer noch dieselben waren Dies f hrte meistens zu wenig befriedigenden Ergebnissen und zu Projekt fehlschl gen wie sehr hohe Kosten zu lange Entwicklungsdauer und u erst fehleranf llige Produkte Daher entstand ein Bedarf an Mechanismen um den Erfolg von Projekten zu gew hrleisten Eine M glichkeit die Qualit t eines Produktes zu steigern ist die Durchf hrung einer Formalen Software Inspektion Diese Review Art wurde in den 70er Jahren von Michael Fagan entwickelt und ist deshalb auch unter der Bezeichnung Fagan Inspektion bekannt Sie ist die urspr ngliche Form der Inspektion und bildet die Basis f r die meisten anderen Inspektionstechniken Als Fagan 1976 seine Review Technik ver ffentlichte hatte er damit die kosteneffektivste manuelle Qualit tssicherungstechnik geschaffen Fagan 1976 Auch heute ber 25 Jahre sp ter setzt ein Gro teil der f hrenden Softwareunternehmen
196. g auch die Gefahr eines gesamten Ausfalls ein st ndiger Begleiter 3 Qualit tssicherung der Software im Automobil Die Software Qualit tssicherung SQS soll sicherstellen dass die Ziele der Unternehmensf hrung bez glich der Qualit t der vom Unternehmen produzierten Software erreicht werden 12 Dies bedeutet nichts anderes als dass sich die Automobilhersteller in Punkto Qualit t keine Ausrutscher leisten d rfen Das Problem in diesem Sektor ist meist die Konkurrenz und so entscheidet vor allem Preisg nstigkeit und Schnelligkeit die jedoch bei life critical Software nie im Vordergrund stehen darf ber den Markterfolg eines neuen Automobils Durch die wachsenden Kundenanspr che stehen Automobilbauer in dem Zwang schnell geeignete Autos auszuliefern um bei dem wirtschaftlichen Wettstreit nicht als Verlierer hervor zu gehen Daraus resultiert dass Entwickler oft gezwungen sind ein Produkt vorzeitig frei zu geben ohne Praxistests oder Einzel berpr fungen der Bauteile durchzuf hren und so gravierende M ngel auftreten k nnen und die Qualit t darunter leidet Die dabei entstandene Software kann folglich durchtr nkt von Fehlern sein was zur Folge hat dass alle Bem hungen des Unternehmens eine marktf hrende Stellung einzunehmen zunichte gemacht werden Doch die Qualit t und die Sicherung der Software sind nicht nur aus diesem kapital schaffendem Grund essentiell Durch die Einbettung sicherheitskr
197. g schwer ist einzusch tzen inwieweit sich gewisse Aufgaben hneln Viele Anf n ger vor allem Sch ler werden beim Durchlesen der Angabe einer Programmieraufgabe nicht sofort beur teilen k nnen ob der Schwierigkeitsgrad in etwa gleich dem der Vorwoche ist 5 1 5 Zeitbudget Erstellung Ausgehend von den bis herigen Aufzeichnungen k nnen wir nun ein Zeit budget erstellen welches in Folge mit der tats chlich ben tigten Zeit verglichen wird Sollten gr ere Ab weichungen auftreten m ssen diese analysiert werden und gegebenenfalls nachfolgende Zeitpl ne angepasst oder der Arbeitsstil ge ndert werden Abb 5 6 Zeitbudget In obigem Beispiel will man auch f r eine Pr fung lernen Dazu ben tigt man Extrazeit die von anderen Aktivit ten weggenommen werden muss Es kann aber auch passieren dass neben geplanten Ereignissen wie Pr fungen auch unerwartete Sonder f lle eintreten Solchen Sonderf llen muss man notfalls auch Freizeit opfern Sollten jedoch st ndig Einschr n kungen des Privatlebens auftreten sollte man auf jeden Fall sein Zeitmanagement berpr fen Denn so viele Sonderf lle kann es gar nicht geben Bei der Erstellung von Zeitbudgets sollte man be r cksichtigen dass es neben fixen Zeiten wie etwa Vorlesungen oder Besprechungsterminen auch variab le Zeit gibt In dieser variablen Zeit kann man dann vorgeschriebene Aufgaben wie etwa Haus bungen oder 4 h Praktika beliebig einteilen
198. ge Zust nde eines Programms z B Laufzeitfehler oder ung ltige Ausgaben Faults hingegen sind interne ung ltige oder fehlerhafte Programmzeilen die mittels Mutationentest erkennbar gemacht werden 1 Zur Erstellung der abgewandelten Programme auch Mutanten genannt dienen sogenannte Mutationsoperatoren Ein solcher Operator ist eine Regel die beschreibt wie ein Konstrukt oder Operand einer Sprache in ein syntaktisch legales modifiziertes oder sogar gel schtes Element umgewandelt wird Mittels dieser Operatoren k nnen durch ein Mutationssystem automatisch Mutanten erzeugt werden 1 Dabei gilt die Annahme dass einfache Fehler durch Kopplungseffekte zu komplexeren Fehlern f hren und erkannt werden 2 Der Ablauf des Mutationentests stellt sich wie folgt dar Zuerst wird das Originalprogramm mit der Menge T getestet Tritt ein Fehler auf wird das Programm verbessert Erkennt die Testmenge T im Originalprogramm keinen Fehler werden Mutanten erzeugt Durch Anwendung von Mutationsoperatoren entsteht jeweils ein neuer Mutant M der einen Fehler F enth lt Kann nun das Mutationssystem durch Anwendung der Testmenge T den Fehler F erkennen 138 159 dann gilt dieser Mutant als killed und ist somit nicht 3 Objektorientiertes Mutationentesten mehr von weiterer Relevanz Fj kann aus zwei Gr nden unentdeckt bleiben 1 der Mutant ist Im Folgenden wird anhand der Programmiersprache funktional quivalent equivalen
199. geht das Dokument im Laufe der Inspektion zeilenweise durch und deckt Fehler und Verst e gegen Programmierstandards auf Er hat generell die Aufgabe sich anhand der vom 99 459 Moderator weitergeleiteten Unterlagen gut auf die Sitzungen vorzubereiten Weiters muss er sich nat rlich aktiv daran beteiligen Der Protokollf hrer bernimmt die Rolle des Berichterstatters ber den Verlauf der Sitzungen Er protokolliert alle Ergebnisse bzw gefundenen Fehler mit und erstellt daraus einen Inspektionsbericht der den Teilnehmern sp ter zur nochmaligen berpr fung zur Verf gung gestellt wird Dieses Dokument dient auch als Grundlage der Fehlerkorrektur Ein ideales Team besteht aus je einem Moderator Autor und Protokollf hrer und drei Gutachtern Eine Person kann allerdings auch mehrere Rollen bernehmen Der Moderator und der Protokollf hrer k nnen zum Beispiel gleichzeitig auch Gutachter sein Der Autor darf allerdings keine weitere Rolle bernehmen da er voreingenommen ist Aus diesem Grund ist es auch m glich dass die Idealbesetzung die wie schon erw hnt aus je einem Moderator Autor und Protokollf hrer und drei Gutachtern besteht von nur drei Personen bernommen wird 3 3 Ablauf Thaller beschreibt Fagans Inspektionsansatz in folgenden 6 Schritten Thaller 2000 e Planungsphase Planning Phase Nach der Fertigstellung eines Dokumentes wird ein Inspektionsteam ernannt Ein Teammitglied bernimmt die Ro
200. gel scht Gibt es mehrere Kanten mit gleichem Maximalwert wird eine davon zuf llig ausgew hlt Danach werden wiederholt SCCs ermittelt und die am st rksten gewichtete Assoziationsbeziehungen gel scht bis keine Zyklen mehr vorhanden sind Eine Testreihenfolge kann nun durch eine topologische Sortierung auf dem azyklischen Graphen ermittelt werden 4 1 1 Beispiel Zuerst wird der Algorithmus von Tarjan angewendet um im gegebenen ORD aus Abbildung 7 eine SCC zu finden Das Resultat ist die SCC F E C A D B H Alle darin vorhandenen Elemente sind transitiv zyklisch miteinander verbunden Nur die Klassen G J und J geh ren der SCC nicht an Von der so gewonnenen SCC muss nun eine Kante gel scht werden um einen Zyklus aufzul sen Daf r werden alle Kanten der SCC gewichtet siehe Tabelle 1 und eine Kante mit maximalem Gewicht wird gel scht In diesem Fall kommen daf r die Kanten As H B und As A C in Frage As H B Hin Bon 3 3 9 As A C Ain Cou 3 3 9 As E A Ein Ag 2 1 2 As C H Cin Ho 3 2 6 As B D Bin Don 1 2 2 As C A Cin Ao 3 1 3 AS E F Ein Fou 2 2 4 As B C Bin Con 1 3 3 AS C E Cin Eo 3 2 6 As F D Fin Dou 1 2 2 Tab 1 Kantengewichtung der SCC Wir entfernen die Kante As A C Als n chster Schritt wird aus der SCC mit Hilfe des Algorithmus von Tarjan die SCC F E C D B
201. gewohnheiten und neuer Bedienbarkeit S hs Werner Seminararbeiten Software Entwicklungsprozess CMM Eine Einf hrung Egger Gudrun Entwicklung von ISO 9000 Antonitsch Birgit Gress Hubert Aspekte des Software Engineering in globalen Projekten Kury Marion Metriken Die Goal Ouestion Metric Methode Jakab Michael Ofner Michael Objektorientierte Softwaremetriken Wernig Pichler Johannes Lassnig Mario Der optimale Software Release Zeitpunkt Peintner Daniel 5 159 19 29 39 49 58 67 76 89 96 102 106 112 118 Zeitmanagement im individuellen Software Entwicklungsprozess unter spezieller Ber cksichtigung schulischer Aspekte Fritz Katharina Glatz Marina 122 Testen Testen komponenten basierter Software Frank Thomas 128 Effektives Testen objektorientierter Software mit Objekt Relations Diagrammen Perauer Stefan Sorschag Robert 132 Mutationentest Objektorientierte Mutanten f r Java Programme Innerwinkler Daniela M tzler Gunar 138 Schlusswort Reflexionen zum Bakkalaureats Seminar aus Angewandte Informatik Sommersemester 2004 Mittermeir Roland 145 6 159 Bakkalaureatsarbeiten 7 459 8 159 Akzeptanztests Unterguggenberger Ingrid M 9960490 iuntergu edu uni klu ac at Abstract Die Bedeutung des Akzeptanztests liegt im recht lichen Sinn darin dass nach dem Test die Verantwor tung f r eine entwickelte Software an den Kunden oder
202. gezeigt Weiters wird noch kurz beschrieben welche Informationen ben tigt werden und wie diese darzustellen sind In Sektion 4 wird danach das Traceability Model mit seinen 10 Eigenschaften analysiert und wie einzel ne Mitarbeiter eines Projektes RT nutzen k nnen Ab schlie end werden noch einige Tools vorgestellt Im Abschnitt 5 wird dann erl utert wie Require ments Tracing zur Qualit tsverbesserung beitragen kann und abschlie end wird noch auf den Traceability Benefit und die damit verbundene Reduktion der Life Cycle Kosten eingegangen 2 Why and How of Requirements Tracing Dieses Kapitel der Arbeit widmet sich dem Wa rum und Wie des Requirements Tracing Wie schon erw hnt wurde handelt es sich bei Requirements Tra cing um einen Prozess der Dokumentation der einer seits die Verbindung zwischen Benutzeranforderungen an das System begutachtet und anderseits das Produkt an sich das entwickelt wird um jene Anforderungen einzuf hren und zu berpr fen 2 1 Das Warum des RT Die Autoren des Papers Why and How of Requi rements Tracing Robert Watkins Softwareingenieur und Mark Neal Software Produktmanager entwickeln schon jahrelang Software fiir das US Verteidigungsmi nisterium und sie identifizierten 4 Ziele warum Requi rements Tracing betrieben werden sollte 2 2 1 1 Verifikation Verifikation hilft uns Softwareanforderungen zu berpr fen Wenn etwas den Anschein macht nicht der
203. gibt die Richtung und den einheitlichen Zweck der Organisation vor Aufga be der F hrung ist es auch ein internes Umfeld zu schaffen und zu erhalten in dem die Mitarbeiter sich voll auf das Erreichen der Ziele der Organisation kon zentrieren k nnen Wichtig ist die Formulierung einer klaren Unternehmensvision und das Leiten durch Vor bild 3 Beteiligung der Mitarbeiter Die Mitarbeiter sind das Herz einer Organisation Um ihre F higkeiten zum Vorteil der Organisation zu nutzen ist die Einbe ziehung in das Organisationsgeschehen wichtig Weiters sollen die Mitarbeiter ermutigt werden aktiv nach Verbesserungsvorschl gen zu suchen 4 Prozessorientierung Ein erw nschtes Ergebnis wird effizienter erreicht wenn die betroffenen Res sourcen und Aktivit ten als Prozesse geleitet werden Es k nnen Teilschritte Schnittstellen Ein und Aus gaben identifiziert werden 5 Systemorientierung Es ist wichtig das Unter nehmen als Gesamtsystem von zusammenh ngenden Prozessen zu verstehen da eine Organisation immer als ein Ganzes funktioniert Das Verstehen und Mana gen dieses Systems von Prozessen erh ht die Effizienz einer Organisation beim Erreichen ihrer Ziele 6 St ndige Verbesserung Da Qualit t keine sta tische sondern eine dynamische Gr e ist muss ein Interesse eines Unternehmens die st ndige Verbesse rung und Weiterentwicklung der Produkte und Prozesse sein 7 Sachliche Entscheidungsfindung Um wirksa me En
204. gs April 1994 pp 91 101 2 R Watkins and M Neal Why and How of Require ments Tracing IEEE Software Juli 1994 pp 104 106 3 M Jake Requirements Tracing Communications of the ACM December 1998 Vol 41 No 12 pp 32 36 4 K Pohl Enabling Requirements Pre Traceability Proceedings of the IEEE Intl Conference on Requirements Engineering ICRE 96 Colorado 1996 5 K Pohl Process Centered Requirements Engineering RSP marketed by J Wiley amp Sons Ltd UK 1996 6 Gotel and A Finkelstein An analysis of the Require ments Traceability Problem Imperial College Department of Computing Technical Report TR 93 41 1993 7 Gotel and A Finkelstein Contribution Structures Proceedings of the Second IEEE International Symposium on Requirements Engineering RE 95 York IEEE Computer Society Press 100 107 1995 8 K Pohl R D mges P Haumer R Klamma K Weiden haupt PRO ART Erfassung und Verwaltung von Anforde rungshistorien RWRH Aachen Informatik 5 Germany 9 B Rahmesh M Edward Ramesh Issues in the Deve lopment of a Requirements Traceability Model Proceedings of the IEEE International Symposium on Requirements Engineering San Diego California Jan 4 6 pp 256 259 10 C Kenny Requirements Traceability Cmpt 856 Pro ject Jan 1996 Quelle http citeseer ist psu edu cache papers cs 21218 http zSzzSz www cs usas
205. gt haben dass die Abnahmekriterien durch das System berhaupt erf llt werden k nnen Dennoch kann es durchaus passieren dass beim Hersteller er folgreich durchgef hrte Tests in der Kundenumgebung scheitern was letztlich zeigt dass der Systemtest den Abnahmetest nicht ersetzen darf 2 2 Test auf Benutzerakzeptanz Dieser Test ist nur dann sinnvoll wenn der Anwen der der Software nicht gleichzeitig auch der Kunde ist Bei diesem Test wird das System durch seine sp teren Anwender und nicht nur durch den Auftraggeber in Hinblick auf die Erf llung ihrer Erwartungen zB be z glich Benutzerfreundlichkeit getestet Wird das System durch unterschiedliche Benutzergruppen ver wendet so sollte jede Gruppe durch einen eigenen Akzeptanztest repr sentiert sein um so m glichst viele verschiedene Nutzungsszenarien abzudecken Zu er w hnen ist auch dass in Hinblick auf den Test auf Benutzerakzeptanz die Erstellung von Prototypen in den fr hen Projektphasen wie zB nach der Anforde rungsanalyse sinnvoll ist um Problemen w hrend des Akzeptanztests vorzubeugen und so gegen Projektende keine b sen berraschungen zu erleben 2 3 Feldtest Soll die zu liefernde Software in sehr vielen ver schiedenen Umgebungen betrieben werden wird dem Systemtest ein Feldtest nachgeschalten dessen Ziel es ist Einfl sse aus nicht vollst ndig bekannten oder nicht spezifizierten Umgebungen zu erkennen und ge gebenenfalls zu beheben 2 3 1 Alp
206. h ufig so dass z B beim Test eines Codefragmentes der Code nach einem bestimmten Kriterium getestet wird ein Fehler gefunden wird dieser korrigiert wird und daraufhin der gesamte Code wieder von vorne gestartet wird um weitere Tests ausf hren zu k nnen Dies erfordert oftmals einen weitaus h heren Zeitaufwand als die Durchf hrung eines Reviews Dennoch ist es in der Praxis h ufig der Fall dass unter Zeitdruck zuerst die Verifikation und Validierung des Produktes vernachl ssigt wird was nat rlich zu einer Verminderung der Qualit t f hrt Ebenso wird die Wichtigkeit und die praktische Relevanz des Themas bei der Ausbildung von Softwareingenieuren oft untersch tzt Es wird viel Zeit daf r aufgewendet wie man Systeme und Produkte plant modelliert und implementiert und dies wird oft auch flei ig ge bt Wie man aber eine gewisse Qualit t in diesen Prozess einbringt darauf wird nur kurz und meist nur theoretisch eingegangen Eine optimale Qualit tssicherung eines Softwareproduktes ist allerdings erst dann gegeben wenn sowohl Reviews als auch Tests durchgef hrt werden Denn nicht alle enthaltenen Fehler sind mit Hilfe eines Reviews identifizierbar Reviews k nnen das Testen zwar erg nzen aber es niemals ersetzen 2 3 Abgrenzung der verschiedenen Review Arten Wie bereits im zuvor erw hnt gibt es einerseits Reviews in Zusammenarbeit mit dem Kunden andererseits auch verschiedene Arten von internen Reviews bei denen
207. h einen Doppel punkt z B ISO 9000 1994 2 4 Aufbau der Normfamilie Version 1987 Die ISO 9000 Normfamilie besteht aus Leitf den und Nachweisstufen ISO 9000 und 9004 sind Leitf den zur Einf hrung und Dokumentation eines QM Systems Sie bestehen aus mehreren Teilen welche die verschiedenen Aspekte und Branchen abdecken Bei spielsweise ist ISO 9000 3 der Leitfaden f r die Anwendung von ISO 9001 auf die Entwicklung Liefe rung und Wartung von Software ISO 9001 bis 9003 sind verschiedene Nachweisstu fen die f r eine Zertifizierung ben tigt werden Alle Nachweisstufen fordern ein dokumentiertes und geleb tes QM System Die Dokumentation muss die Normanforderungen abdecken und besteht aus einem Handbuch und Verfahrens und Arbeitsanweisungen vgl Funk00 S 7 ff e ISO 9000 Diese Norm erkl rt grundlegende Quali t tskonzepte und deren Begriffe Sie ist der Leitfaden zur Auswahl und Anwendung der Nachweisstufen ISO 9001 9002 9003 e ISO 9001 Diese Norm ist die Nachweisstufe f r Entwicklung Produktion Montage und Wartung Sie ist die umfassendste der drei Nachweisstufen e ISO 9002 Sie ist die Nachweisstufe f r Produktion und Montage e ISO 9003 Diese Norm bezieht sich nur auf die Qua lit tssicherung in der Endpr fung e ISO 9004 Sie ist ein bergeordneter Leitfaden und soll bei der Auswahl von Qualitatssicherungs Elementen behilflich sein Es gibt 20 solcher Elemen te einige davon w ren Prozesslenk
208. ha Test Dieser Test ist der erste durchge f hrte Test Er wird in den R umen des Entwicklers von einem oder mehreren Anwendern in Gegenwart des Entwicklers durchgef hrt 2 3 2 Beta Test Der Beta Test ist der Probebetrieb einer Vorabversion eines Softwareprodukts durch re pr sentative Anwender in der Einsatzumgebung des Kunden Dabei werden Probleme und Fehler protokol liert und an den Anbieter zur ckgemeldet Dieses Vorgehen ist f r den Hersteller besonders dann interessant wenn die Verschiedenheit der m gli chen Einsatzumgebungen mit denen die Software im realen Betrieb konfrontiert sein wird nur schwer abge sch tzt werden kann oder wenn aufgrund der Anzahl der m glichen Einsatzumgebungen ein Test mit den 10 159 verschiedenen Konfigurationen im Hause des Herstel lers aus Kostengr nden nicht m glich ist 3 Was sagt ISO 9000 3 ber Akzeptanz tests Dieses Kapitel wurde zur G nze dem Buch ISO 9000 3 10 entnommen 3 1 Allgemeines Der Akzeptanztest wird vom K ufer durchgef hrt und sollte gut geplant werden Deshalb ist es ratsam einen Akzeptanztestplan aufzustellen der den Zeit plan die Ressourcen Rollen Verantwortlichkeiten Testf lle und Erfolgskriterien im Vorhinein plant Auch der Entwurf der Testf lle ist sehr wichtig und sollte genau vorgenommen werden K ufer und Ver k ufer m ssen in der G ltigkeit der Akzeptanztestf lle bereinstimmen genauso wie in der Genauigkeit der Pr fung
209. hafte Software wird oft als un zuverl ssig betrachtet und deshalb nicht verwendet 2 Aus diesem Grunde ist es wichtig dass man ausrei chend Zeit zum Testen der einzelnen Methoden ver wendet 4 1 5 Projektbericht Wurde w hrend der einzelnen Phasen wie geplant immer wieder dokumentiert so schreibt man in dieser Phase zirka zehn Seiten Bericht pro Tag da man nur noch die Berichte zusammenf gen muss 3 4 2 Entwicklung eines Zeitplans Sowohl Humphrey 1 als auch Thaller 4 und Ricketts 3 schlagen Zeitpl ne in Form von Gantt Charts Abb 4 3 vor Diese Pl ne bestehen aus st ndlichen oder w chentlichen Meilensteinen die verdeutlichen sollen wann eine gewisse Phase des Wasserfallmodells oder in der Schule eines gr eren Projekts fertig gestellt sein muss W hrend bei einem Projekt das nur von einer Person durchgef hrt wird keine Synchronisation des Planes notwendig ist ist eine solche bei Teamarbeit von gro er Bedeutung Zeitpl ne d rfen in keinem Projekt fehlen da sie je den einzelnen mehr oder weniger dazu zwingen sich an die darin enthaltenen zeitlichen Vereinbarungen gekennzeichnet durch Meilensteine zu halten Durch die Meilensteine bietet sich auch die M glichkeit ge nau zu pr fen wo man sich in einem Projekt befindet und bei Verzug rechtzeitig zu reagieren GEEAE sIe Js s n Projektmonate nov oez jan res mar Apr mal sun su au se
210. hen Charakte ristika und Zielen interpretiert werden miis sen Das hei t dass die Messung in top down Manier zu definieren ist und ferner eine Fokussierung auf die Ziele und Modelle gegeben sein muss 1 GQM Goal Question Metric ist eine Vorgehens weise die diesem Ziel getriebenem Top Down Mo dell folgt und nach diesen Kriterien zu den im gew hl ten Kontext relevanten Metriken f hrt 2 Goal Question Metric Methode Der GQM Ansatz basiert auf der Annahme dass eine Organisation welche zielgerichtete Messungen durchf hren m chte zuerst die Ziele f r sich selbst und ihre Projekte festlegen muss Ausgehend von die sen m ssen in weiterer Folge die Daten welche diese Ziele definieren sollen identifiziert werden und basie rend auf diesen ein Rahmenwerk zur Interpretierung geschaffen werden Es ist also wichtig die Informati onsanforderungen die eine Organisation hat zu identi fizieren sodass diese quantifiziert werden k nnen um zu analysieren ob die Ziele erreicht wurden 1 106 159 2 1 Ebenen der GQM Methode Das GQM Modell inkludiert drei verschiedene E benen siehe Abbildung 1 Es beginnt nach einem Top Down Schema indem zuerst ein spezielles Ziel Goal definiert wird aus welchem dann mehrere Fra gen Question abgeleitet werden k nnen die dieses Ziel definieren sollen Die Metriken Metric werden so ausgew hlt dass die daraus gewonnenen Daten die im vorhergehenden Sc
211. hren Jede Klasse rai E Es Pres besitzt nur eine direkte Elternklasse Die Subklasse er ee ee kann die geerbten Methoden und Variablen mithilfe mutant des Schl sselwortes super aufrufen Die Umsetzung der Vererbung in Java erlaubt das berschreiben von is i a cine I Methoden das Verstecken von Variablen und mutants I Klassenkonstruktoren Quit berschreiben von Methoden Die Subklasse kann Methoden der Superklasse neu definieren Die Methode der Subklasse hat dieselbe Signatur aber eine unterschiedliche Implementierung Figure 1 Ablauf Mutationentestprozess 2 139 159 Verstecken von Variablen Java bietet die M glichkeit in der Subklasse dieselbe Variable Typ Name wie in der Superklasse zu definieren Das hat den Effekt dass die Variable der Superklasse vor der Subklasse versteckt ist Klassenkonstruktoren Um den Konstruktor der Superklasse zu verwenden muss ein expliziter Aufruf mit super erfolgen Dieser Aufruf muss die erste Anweisung im Konstruktor der Subklasse sein Ist diese Anweisung nicht vorhanden wird sie vom Java Compiler implizit eingef gt und der Default Konstruktor der Superklasse ausgef hrt 6 Polymorphismus Unter Polymorphismus ist die F higkeit einer Gr e Objekte und somit implizit die mit ihnen verbundenen Methoden Funktionen Variablen etc zu verstehen zur Laufzeit unterschiedliche Auspr gungen bzw Formen annehmen zu k nnen
212. hrenden Person Da in der agilen Softwareentwicklung ein evolution rer Ansatz vorherrscht bedeutet dies dass ein Unit Test zu jedem Zeitpunkt in der Entwicklung zu 100 erf llt werden muss Ist dies nicht der Fall so muss dies sichergestellt werden bevor die Entwicklung vorangetrieben werden kann in diesem Zusammenhang spricht man von 36 159 Regressionstests Diese Gesamtsicht macht die Aus f hrung von solchen Tests kompliziert da stets die Testf lle f r das gesamte Produkt konzipiert werden m ssen Um dies zu erleichtern kann sich der Ent wickler den bereits erw hnten Testframeworks bedie nen Frameworks generieren automatische Testf lle und berpr fen die Ausf hrung Der Einsatz solcher Werkzeuge ist aber mit Vorsicht zu genie en da ge treu der Forderung Testf lle vor dem Entwickeln zu definieren eine Verwendung von solchen Frame works kaum m glich ist Trotz dieser Einschr nkung k nnen solche Frameworks vor allem bei Tests ber das gesamte Produkt sehr hilfreich sein Man kann hier von einer 80 20 Regel ausgehen 20 automati sierte Tests und 80 vom Entwickler erstellte Tests Unit Tests obwohl n her bei der Software sind gleich bedeutend wie Akzeptanztest und sollten daher nicht h her bewertet werden um so der Gefahr der Vernach l ssigung der Akzeptanztest zu entgehen 6 4 Performance Tests Performance Tests dienen dazu die Leistung des Softwaresystems zu quantifizieren Diese Art von
213. hritt definierten Fragen beant worten k nnen Aus der Auswertung der Fra gen Antworten kann im letzten Schritt festgestellt wer den ob bzw inwiefern die Ziele erreicht wurden Die folgenden Informationen stammen aus 1 Goal 1 Goal 2 Question Question Question Question Metric Metric Metric Metric Metric Abbildung 1 GQM Modell Konzeptuelle Ebene Goal Aus einer Vielzahl von Griinden wird ein Ziel fir ein bestimmtes Objekt definiert Dieses kann auf un terschiedliche Qualit tsmodelle Bezug nehmen und verschiedene Bed rfnisse und Sichtweisen ber cksich tigen Objekte auf welche sich die Ziele beziehen k n nen sind e Produkte Artefakte Arbeitsergebnisse und Dokumente die w hrend des System life cyc le erstellt werden z B Spezifikationen De signs Programme Testumgebungen e Prozesse Software bezogenen Aktivit ten z B Spezifizieren Designen Testen Inter viewen e Ressourcen Mittel welche von Prozessen gebraucht werden um einen Output zu gene rieren z B Personal Hardware Software B ror umlichkeiten Die gewonnenen Ziele dienen als Ausgangspunkt f r den GQM Ansatz Operative Ebene Question Eine Menge von Fragen charakterisiert die Art wie ein gewisses Ziel evaluiert werden kann Sie dienen also zur Feststellung ob ein gewisses Ziel erreicht wurde Die Fragen
214. hrun gen freie Themenwahl mag dazu einiges beigetragen haben Jedenfalls waren zwei Wochen nach Wiederauf nahme des Lehrbetriebs nur mehr 8 Bakkalaureatsstudie rende und 18 Seminaristen 7 Zweier Teams und 4 Ein zelvortragende verblieben Diese Personen beendeten das Seminar auch eine Zweiergruppe jedoch negativ Um den laufenden Arbeitsfortschritt sicherzustellen und allenfalls weiteres inhaltliches Feedback insbeson dere auf Reaktionen auf den Begutachtungsprozess zu geben wurden f r die Phase nach den Osterferien Kurz pr sentationen anberaumt F r diese standen pro Seminar thema strikt maximal 4 Minuten pro Bakkalaureatsthema 5 min bzw 3 Folien die vorab abzugeben waren um rasche Pr sentationsfolge zu gew hrleisten zur Ver f gung Der in einer e mail gemeinsam mit einer Pau schalkommentierung der Begutachtungen in der Karwo che angek ndigte Kurzvortragsblock verfolgte neben den erw hnten Zielen auch die Absicht die f r die Pr senta tionen unbedingt erforderliche Einhaltung von Vortrags effizienz sowie das Einhalten der zeitlichen Rahmenbe dingungen zu sichern Inhaltliches wurde im Anschluss an diese Referate nur in wenigen F llen diskutiert Weit eher konnten unterschiedliche Pr sentationsstrategien L sungen der Folien und Zeitbeschr nkung analysiert und besprochen werden Im Anschluss an die Kurzpr sentationen wurde der Zeitplan der Vortragsphase festgelegt und abgesehen von einem Fragetermin
215. hung zwischen 2 Dokumentsegmenten sprich ein bestimm tes Dokument ist in bereinstimmung mit einem vor hergehenden Dokument mit dem es eine Art Verh lt nis hat Dokumenten Traceability garantiert weiters dass alle Komponenten eines Dokumentes eine ver wandte Komponente in einem anderen Dokument besitzen Konsistenz und Vollst ndigkeitsbedingun gen werden innerhalb von und ber alle Dokumente angewandt 4 1 8 Horizontales und vertikales Traceability Vertikales Traceability referenziert die Assoziation zwischen verschiedenen Software Life Cycle Objekten SLCO Ein Beispiel daf r w re die Beziehung zwi schen einem Anforderungsstatement und einem De signstatement Horizontales Traceability referenziert die Assoziation zwischen gleichen SLOC Ein Bei spiel f r diese Traceabilityart w re eine Eltern Kind Beziehung zwischen aufgespalteten Datenflussdia grammen einerseits und andererseits abgeleitete Bezie hungen zwischen Anforderungsstatements 4 1 9 Automatische Unterst tzung f r Traceability Automatischer Support f r Traceability kann sehr wertvoll f r gro e bzw komplexe Systeme sein Wenn die Unterst tzung manuell durchgef hrt wird sind die Aufgaben zeitraubend und fehleranfallig Au erdem werden F higkeiten der Benutzer Traceability Daten zu analysieren durch den schieren Datenbestand be grenzt Als Schlussfolgerung ergibt sich daraus dass um fassende Teil Modelle darunter werd
216. hvollziehbar ist Somit eine kurze Antwort auf die Frage Welche Art der Informationen m ssen notiert werden Um Pre Traceability jedoch zu erm glichen m ssen die An forderungen im Rahmen eines Anforderungsprozesses definiert sein 12 Hierf r dient ein 3 dimensionales Ger st das aus den Achsen e Specification e Representation und e Agreement besteht 4 Specification A Mp ee oe ae eae 1 complete fair T common view opaque 1 I 1 l Representation informal semi formal formal ersonal views Abb 2 Das 3 dimensionale Framework 4 68 159 e Dimension der Repr sentation als Grundlage f r die formale Entwicklung bewegt sich die Anforderungsdimension von einer anf nglich ziemlich formlosen zu einer formalen Repr sen tation die Idealerweise mit einer formalen Spe zifikation endet und leicht in nachvollziehbaren Code umgewandet werden kann Diese Dimen sion ist leider nicht sehr einfach zu modellieren da unterschiedliche Personen in bestimmten Si tuationen eine andere Art der Darstellung be vorzugen Wenn diese Darstellungen modelliert werden kommt es auf dieser Linie meist zu technischen Problemen die eine Mensch Computer Interaktion erfordert 12 e Dimension der Spezifikation ein zweites of fensichtliches Ziel ist es mit einer kompletten Systemspezifikation abzuschlie en die jeder mann versteht und nachvollziehen ka
217. ich in der Praxis nicht sehr hilfreich Denn sie m te wohl so kompliziert sein dass sie niemand versteht und w rde keine R ckschl sse erm glichen wie denn die Qualit t verbessert werden k nnte Die meisten der in dieser Arbeit beschriebenen Metriken sind wohl eher ungeeignet um sie dem Management zu pr sentieren Dementsprechend gering ist bei ihnen die Gefahr dass diese Dysfunktion eintritt Dieses Risiko besteht vor allem bei Metriken die einen auch f r Nicht Informatiker verst ndlichen Output produzieren Darunter fallen einerseits sehr simple Metriken wie LOC und andererseits komplexe Metriken die versuchen ein sehr einfaches aber aussagekr ftiges Ergebnis zu liefern wie Martins OO Design Quality Metrik 6 Conclusio W re der Nutzen von Software Metriken in der Praxis unumstritten w rden sie wohl schon l ngst viel mehr Unternehmen und auch Open Source Entwickler einsetzen berraschenderweise hat anscheinend gerade die kontroversielle Metrik von Robert Martin in der Open Source Community etwas Anklang gefunden Trotz der Schw chen und aller Kritik die zum Thema Software Metriken ge u ert wurde und auch heute noch ge u ert wird sehe ich in ihnen vielversprechende Werkzeuge f r die zuk nftige Softwareentwicklung Ob und wie man sie am besten zum Einsatz bringt h ngt nicht zuletzt vom gew hlten Entwicklungsproze ab Gerade Methoden der agilen Softwareentwicklung wie eXtreme Programming die
218. ichen F higkeiten ab sollte das Programm in der Lage sein sich diesen anzupassen Entwickler neigen dazu aufgrund ihres technischen und formalen Kontexts Anforderungen w rtlich zu nehmen Es ist nicht immer direkter Kontakt zwischen Entwickler und Benutzer gegeben und so mag die Spezifikation die einzige Basis sein auf der der Entwickler aufbauen kann Werden spezielle Anforderungen gestellt besonders im Bereich der Effizienz neigen viele Entwickler dazu diese mit eisernem Gehorsam auszuf hren und zwar meist zu Lasten anderer Aspekte Sagt man einem Entwickler beispielsweise er solle Speicherplatz minimieren so wird das Programm voraussichtlich auf dem Gebiet der Geschwindigkeit weniger leisten als es k nnte Aufgrund ihres hohen Grades an Wissen ber Programmentwicklung im Allgemeinen und spezielle Produkte sind Entwickler voreingenommen und neigen dazu die berzeugung in sich zu tragen den Weg den eine Entwicklung nehmen soll zu kennen Ungenauigkeiten bei Fragestellung oder Antworten in der Anforderungsanalyse geben Entwicklern Freiheiten eigene Pr ferenzen einflie en zu lassen Doch Entwickler sollten niemals versuchen dem Benutzer das zu geben was er braucht sondern das was er haben will wenn ein Kunde nicht willig ist sich beraten zu lassen dann haben seine W nsche Vorrang vor der Erfahrung des Entwicklers Gibt es hingegen im Stadium der Anforderungsanalyse weder Kunden noch Benutzer so bleibt dem Entwickle
219. icht der Lehrveranstaltungsleitung unspekta 146 159 kul r Die Ergebnisse variierten zwischen den Teilneh mern jedoch so deutlich dass die Ank ndigung die Qualit t der Gutachten in die Seminarnote einflie en zu lassen siehe Seminarordnung jedenfalls als sinnvoll und notwendig anzusehen ist Um auch diesbez glich f r Klarheit zu sorgen wurde in der Woche nach den Osterferien die Gutachten f r die Extended Abstracts waren bereits zugestellt ein Punktezwischenstand be kannt gemacht Dies bot auch jenen wenigen die sehr divergente Gutachten erhielten die Chance zu sehen wie die Lehrveranstaltungsleitung die ja nur ein normales Gutachten abgab ihre Einreichung beurteilte Allerdings ist darauf hinzuweisen dass die Mehrzahl der studen tischen Gutachten hohe einige sogar extrem hohe Quali t t hatten Festzuhalten ist dass jede Arbeit von mindestens drei studentischen Reviewern und vom Lehrveranstaltungs leiter begutachtet wurde Um die Belastung der stu dentischen Gutachterinnen und Gutachter mit jeweils drei Arbeiten konstant zu halten bekamen allerdings Arbeiten die von Paaren eingereicht wurden eine bertrieben hohe Anzahl von Gutachten Nach den Osterferien kam es zu einem drastischen Schwund an Teilnehmern Dieser wurde teils unterschied lich begr ndet teils erfolgte er stillschweigend Der Hin weis dass man mit Plagiatrie keinesfalls zu einem positi ven Abschluss gelangen kann siehe Abschnitt Erfa
220. icht werden Diese Punkte wurden aber schon ausf hrlich in Kapitel 3 4 behandelt 3 2 Post Traceability Bei Post Traceability handelt es sich um die Nach vollziehbarkeit der Anforderungen vorw rts hindurch durch die Verfeinerung die Entwicklung und die Ver wendung eines Systems um die neueren Stadien zu begutachten und sie von jenen neuen Artefakten wieder zur ck auf die urspr ngliche Spezifikation zu verfol gen Die Anforderungsspezifikation fungiert als eine Art Grundlinie von der aus verglichen wird Vergli chen werden die Anforderungen die bis jetzt umge setzt wurden mit jenen die zu Beginn spezifiziert wurden Wenn nderungen an den Anforderungen vorgenommen werden m ssen sie durch alle Artefakte des Systems fortgepflanzt werden die sich auf jene ge nderten Anforderungen beziehen 10 3 2 1 Probleme des Post Traceability Das Post Traceability bezieht sich auf die Aspekte der Anforderungen zu jenem Zeitpunkt wenn sie in die Anforderungsspezifikation mit eingeschlossen werden Nachdem dies nicht gerade ein leichtes Unterfangen ist kommt es auf Grund der F lle der Anforderungen fters zu Problemen Es werden entweder Anforderun gen verloren nicht mit bernommen und oder welche hinzuaddiert Requirements Post Traceability ist auch f r die nderung der Integrationen wichtig da sie eine Kennzeichnung der Entwicklung von Design und Implementierungs nderungen erm glicht 3 3 Support von Pre und Po
221. ie der Softwareent wicklungsprozesse Diese Bezeichnung umfasst eine F lle von Methoden die sich durch eines klar gegen ber den herk mmlichen Methoden unterscheiden soll Agilit t Mit dem Wort agil soll die besondere Mobilit t gegen ber gesteigerten Kundenanforderun gen zum Ausdruck gebracht werden 29 159 Agile Softwareentwicklungsprozesse oder light weight Prozesse im Vergleich dazu spricht man von heavyweight Prozessen im Sinne der traditionellen Softwareentwicklung wurden mit dem Aufkommen von eXtreme Programming XP 6 7 begr ndet Durch den steigenden Anteil der Internetsoftware 8 wurde erkannt dass herk mmliche Methoden mit ihren ausgepr gten Analyse und Designphasen schwer f r den schnellen Produktzyklus der im Internet vorherrscht geeignet sind Au erdem k nnen her k mmliche Methoden schlecht beziehungsweise gar nicht auf ge nderte Kundenanforderungen w hrend des Projektverlaufes reagieren Dies ist hinsichtlich der Qualit t eines Produktes aber wesentlich da das Quali t tskriterium der Korrektheit insbesondere vom Ver st ndnis des Kunden abh ngig ist Agile Softwareentwicklung wird gerade in dieser Hinsicht als Allheilmittel insbesondere in der Ge meinschaft der Verfechter der agilen Methoden gese hen Daher ist es schwer objektiv zu beurteilen ob sich durch den Einsatz von agilen Methoden hinsichtlich der Qualit t Verbesserungen erzielen lassen k nnen 3 1 Ba
222. iel bei der Findung eines bearbeitbaren Themas behilflich zu sein zu weit zu eng Titel zu unklar oder zu wenig attraktiv und allenfalls generelle Hinweise zur Literatursuche be z glich des gew hlten Themas zu geben hatte das w chentliche Treffen in dieser Phase vor allem das Ziel sicherzustellen dass die Studierenden diese Vorberei tungszeit aktiv nutzen Eine Vorsichtsma nahme die sich nicht f r alle wohl aber wie die Art einiger Themen nennungen in der zweiten Seminarwoche vermuten lie en doch f r einige Studierende als notwendig erwies Im studentischen Feedback teiloffener Fragebogen mag einer dieser beiden Veranstaltungstage als berfl s siger Pr senztermin kritisiert worden sein Ich w rde ihn dennoch nicht entfallen lassen Sehr bedenkenswert er scheint jedoch die Kritik dass die daf r aufgewendete Zeit dazu f hrte dass ein Referat ber methodische Hin weise erst nach Einreichung der Extended Abstracts gege ben werden konnte Ein solches Kurzreferat ist unbesehen dessen dass alle Studierenden bereits mindestens ein Proseminar aus Informatik absolviert hatten erforderlich Allerdings wurden Hinweise zur Textsorte Extended Abstract auch in den bisherigen Spezialseminaren nicht zuletzt aus Gr nden der ex post h heren Aufmerksam keit erst nach der ersten Feedback Runde gegeben dort allerdings elektronisch in Schriftform Der Begutachungsprozess der Extended Abstracts ver lief aus S
223. ientierung entsprechend ber cksichtigten Vor allem Chidamber und Kemerer leisteten bei den OO Metriken Pionierarbeit 1 1 Source Code als Basis der Berechnung Metriken in der Softwareentwicklung befassen sich mit sehr unterschiedlichen Aspekten Das Spektrum reicht von Metriken die den Entwicklungsproze selbst betrachten ber Metriken f r das Design bis hin zu Metriken die Aussagen ber das Laufzeitverhalten Performance Resourcenbedarf der entwickelten Software treffen Diese Arbeit beschr nkt sich jedoch auf Metriken die sich auf Basis des Source Codes einer Software errechnen lassen Mit ihrer Hilfe sollen Aussagen ber die Komplexit t und Qualit t des Source Codes getroffen werden k nnen Wesentlich ist auch dass diese Metriken voll automatisch und somit kosteng nstig errechnen lassen Sie sollen einen Einblick in die entwickelte Software geben die Entwickler auf m gliche Probleme hinweisen und letztendlich beim Treffen von Entscheidungen im Entwicklungsproze helfen Gerade bei Entwicklungsprozessen 58 159 in denen sehr fr h Code geschrieben wird bieten sich solche Metriken bzw Werkzeuge die diese f r die verwendete Programmiersprache berechnen an OO Metriken sind weitgehend programmiersprachen neutral definiert Damit sollen sie universell auf alle objektorientierten Programmiersprachen anwendbar sein k nnen aber nicht immer auf alle spezifischen Merkmale einer konkreten Programmie
224. ifa A Steer Break by Wire Zentralverrierelung EN I Drive Sitzheizw RDS TMC x os a reel halteunterst zung Autom Spracheingabe re ar SW Update Force Feedback Pedal 2000 Vernetzungsgrad BMW Ca IT Abbildung 1 Die Entwicklung der Elektronik und Software im Automobil 10 Des fteren wird der Begriff Elektronik fallen wobei es wichtig ist diesen vorerst zu definieren damit der Zusammenhang zur verwendeten Software hergestellt werden kann Elektronik Im Mittelpunkt dieses Zweiges stehen u a der Entwurf und die Anwendung von elektronischen Schaltungen in Ger ten umgangssprachlich bezeichnet man diese Schaltungen ebenfalls als Elektronik Elektronische Schaltungen realisieren verschiedene Funktionen zur Informationsverarbeitung au erdem werden logische Operationen wie z B die elektronischen Abl ufe in 39 159 einem Computer durch elektronische Schaltungen verwirklicht 28 Eine besondere Wechselbeziehung der Elektronik besteht zur Informatik zum einen liefert die Elektronik die f r die angewandte Informatik notwendigen technischen Grundlagen elektronischer Rechenmaschinen andererseits erm glichen die Verfahren der Informatik erst komplexe elektrotechnische Systeme 2 Heutiger Standpunkt Experten nach wird der weltweite Markt der Automobilindustrie in den n chsten Jahren von 125 auf 270 Mrd Euro steigen und so auch der Prozentsatz der eingebauten Software im Auto Der Software Anteil
225. ig zu sein solche Grenzwerte zu finden Manche Forscher etwa 11 meinen sogar dass erstgenannte Grenz werte f r bis heute definierte objektorientierte Metriken gar nicht existieren Und da die Entwicklung von Software auch immer eine menschliche Komponente enth lt etwa System designer Programmierer und die beteiligten Personen un terschiedliche Erfahrungen und Wissen besitzen scheint es in der Tat fraglich ob solch allgemein g ltige Grenzwerte ex istieren Viel mehr scheint es als ob es anstatt fixer Grenz werte Grenzbereiche gibt die eine Art von Richtlinien f r die an der Systementwicklung beteiligten Personen darstellen IWas der Idee entspricht empirisch festgelegter Grenzwerten Fehleranf lligkeit Fehleranf lligkeit Messwert Messwert Grenzwert Grenzwert Abbildung 1 Verschiedene Typen von Grenzwerten OO Metrik Se c Fehleranf lligkeit Gr e En Legende Kausale Beziehung Assoziation Abbildung 2 Pfaddiagramm dass den Verzerreffekt der Klassengr e auf objektorientierte Metriken illustriert 6 EINFLUSS DER KLASSENGROSSE AUF METRIKEN Mit dem Aufkommen objektorientierter Softwaremetriken wurde es n tig diese sowohl theoretisch als auch empirisch zu validieren Obwohl mehrere Metriken berpr ft wur den und ein Gro teil der Literatur zur Validierung etwa 1 bez glich der Metriken von Chidamber und Kemerer von objektorientierten Metr
226. igkeiten zwischen zwei Klassen A und B verwendet KA steht hierbei f r die Klassenabh ngigkeit und ist aus der Menge As Ag e Vererbung Eine Vererbungsbeziehung I A B zwischen zwei Klassen besteht wenn sich in der Klassendefinition der Subklasse A das Schliisselwort extends B befindet e Aggregation Es existiert eine Abh ngigkeit Ag A B genau dann wenn im Konstruktor von A ein Statement this var new B existiert e Assoziation Eine Abh ngigkeit As A B exisitiert genau dann wenn entweder o m B var die Definition einer Methode oder eines Konstruktors der Klasse A ist Dies nennt man Parameter Assoziation o Es exisitiert ein Variablenzugriff b var in der Klasse A und die Variable b ist eine Instanz der Klasse B wobei b keine Klassenvariable von A ist Man nennt dies Variablen Zugriffs Assoziation o Die Klasse A enth lt den Methodenaufruf b m und die Variable b ist eine Instanz der Klasse B wobei b keine Klassenvariable von A ist Man nennt dies Methoden Aufruf Assoziation 3 2 Generischer Algorithmus zur Konstruktion von ORDs Die von Kung und Labiche vorgestellten Methoden zur Konstruktion von ORDs haben einen entscheidenden Nachteil Sie sind ungenau Dies f hrt zu berfl ssigen bzw fehlenden Kanten im ORD Wir wollen einen generischen Algorithmus von Milanova et al vorstellen der auf einer vorhergehenden Klassen Analyse basiert 1 Der Vorteil dabei ist dass die Genauigkeit des ORDs
227. ihre Sicht auf Objektorientierte Software Metriken und Daniel PEINTNER zeigt in Der optimale Software Release Zeitpunkt dass dieser anhand entsprechender Messungen und Prozess berwachung tats chlich ermittelt werden kann Schlie lich wenden sich Katharina FRITZ und Marina 9 4159 GLATZ in ihrer Arbeit Zeitmanagement im individuellen Software Entwicklungsprozess unter spezieller Ber cksichtigung schulischer Aspekte der Erkenntnisgewinnung ber pers n liche Leistungsf higkeiten im Bereich der Software Entwicklung zu Hierbei ist zu erw hnen dass die beiden Lehramtsstudierenden mit bertragung der allgemeinen Software Engi neering Thematik auf den Schulbereich und die entsprechende kritische Auseinandersetzung mit dem Thema aus schulischer Sicht absolutes Neuland betreten haben Den abschlie enden Block bilden drei Arbeiten zur Test Thematik Thomas FRANK zeigt in Testen komponenten basierter Software dass die zunehmend st rker eingesetzte Kompo nentenbauweise von Software auch auf den Testprozess R ckwirkungen hat Stefan PERAUER und Robert SORSCHAG pr sentieren mit Objekt Relations Diagrammen ein Hilfsmittel f r Effektives Testen objektorientierter Software und Daniela INNERWINKLER und Gunar M TZLER zeigen in Mutationentest Objektorientierte Mutanten f r Java Programme wie die Wahl von Programmierparadigma und spezifischer Sprache in die Wahl der Mutanten zur Pr fung der Effektivit t eines Satzes von Testdaten eingeht
228. iken diese als validiert betrachtet haben viele der Validierungsstudien den potenziellen Ver zerrungseffekt der Klassengr e auf die einzelnen Metriken ignoriert 10 Das kommt daher dass viele der durchgef hrten Analysen eindimensional sind sie modellieren nur die Beziehung zwis chen der Metrik und der abh ngigen Variable So wurde etwa in 4 mit Hilfe von eindimensionalen Modellen die Beziehung zwischen der Fehleranf lligkeit von Klassen und objektorientierten Metriken sowie die M glichkeit wie etwa Metriken eingesetzt werden k nnen um vorherzusagen wo Fehler vorhanden sind untersucht Abbildung 2 siehe 8 zeigt den Verzerreffekt der Gr e auf die Fehleranf lligkeit Der Pfad a repr sentiert die weit verbreitete Annahme dass Metriken ein Bezugselement f r die Fehleranf lligkeit sind Pfad b zeigt einen positiven urs chlichen Zusammenhang zwischen Gr e und Fehleranf lligkeit Der Pfad c stellt eine positive Assoziation zwischen Metriken und Gr e dar Wenn diese Graphik der Realit t entspricht dann verzerrt die Gr e die Beziehung zwischen Metriken und Fehleranf l Gr ere Klassen f hren automatisch zu einer h heren Fehlerwahrscheinlichkeit ligkeit und da die Gr e ein positiver Verzerrer ist werden die Assoziationen immer positiver dargestellt als sie wirk lich sind In 10 und 8 wurden Analysen bez glich der Auswirkung des Verzerreffektes der Gr e auf bereits validierte
229. ildren NOC ist eine weitere Metrik von Chidamber und Kemerer 2 NOC ist die 9Bei Mehrfachvererbung sind mehrere unterschiedliche Distanzen zur Wurzel m glich 61 159 Anzahl der direkten Subklassen einer Klasse Mehr Subklassen bedeuten mehr Reuse weil Vererbung von Methoden ja auch eine Form des Reuse darstellt Ein sehr hoher NOC Wert kann aber auch ein Indiz daf r sein da die Klasse unpassend stark abstrahiert oder das Konzept der Vererbung falsch eingesetzt wird Generell kann davon ausgegangen werden da eine Klasse mit hohem NOC auch gro en Einflu auf das Design der Software hat und das diese Klasse auch ausf hrlich getesten werden sollte Auch bei dieser Metrik ist es schwer allgemein g ltige Aussagen ber optimale Werte zu treffen Sie kann nat rlich eingesetzt werden um Klassen mit au erordentlich hohem NOC zu finden 3 4 Kopplung Bei der klassen bergreifenden Analyse objektorientierter Software kann man auch Metriken einsetzen die Aufschlu ber die Abh ngigkeiten zwischen den Klassen geben Unter Kopplung fallen blicherweise alle Abh ngigkeiten au er der Vererbungsbeziehung D h Aufrufe von Methoden aber auch direkter Zugriff auf Attribute anderer Klassen bedingen Kopplungsbeziehungen 3 4 1 Coupling Between Object Classes Auch zur Bestimmung der Kopplung haben Chidamber und Kemerer eine Metrik entwickelt Coupling between object classes CBO wird f r einzelne Klassen errechnet
230. ildung 4 Rework Anteil in einem Software Projekt Wheeler 1996 Eine effektive Durchf hrung der Inspektion erm glicht eine wesentliche Verbesserung der voraussichtlichen Terminplanung eine substantielle Reduktion der Entwicklungs und Wartungskosten eine Erh hung der Kundenzufriedenheit sowie der Moral des Entwicklungsteams Da die Formale Inspektion im Gegensatz zum Testen in jeder Phase des Software entwicklungsprozesses eingesetzt werden kann werden durch ihre Anwendung Defekte dieser Art noch vor Abschluss der jeweiligen Phase erkannt und k nnen eliminiert werden wodurch das Auftreten von Folgefehler vermieden wird Wird w hrend der einzelnen Entwicklungsphasen eines Projektes regelm ig eine Inspektion durchgef hrt so werden bis zur Fertigstellung 2 3 der enthaltenen Defekte erkannt und behoben sein Doch nicht nur die finanziellen Aspekte spielen eine wichtige Rolle auch die Zuverl ssigkeit und Verwendbarkeit eines Softwareproduktes wird durch den Einsatz einer Inspektion erheblich gesteigert Au erdem werden auch allf llige Wartungskosten reduziert Die Inspektion ist eine sehr effiziente Methode um Fehler zu vermeiden da viele Defekte gleichzeitig aufgedeckt werden k nnen wogegen bei einem Software Test der Code oft nach einem fehlerhaften Resultat abgebrochen und der Fehler zuerst korrigiert werden muss F hrt man eine Inspektion durch so ist nicht nur eine erhebliche Verbesserung der Softwarequalit t z
231. ile Manifesto http agilemanifesto org Besucht am 12 April 2004 11 Miller G G The Characteristics of Agile Software Processes The 39 International Conference of Object Oriented Languages and Systems TOOLS 39 Santa Barbara CA July 29 August 03 2001 12 Boehm B Get Ready For The Agile Methods With Care Computer 35 1 pp 64 69 13 Turk D France R Rumpe B Limitations of Agile Software Process XP 2002 2002 14 Takeuchi H Nonaka I The New Product Development Game Havard Business Review Jan Feb 1986 pp 137 146 15 Schawber K Beedle M Scrum Development Process OOPSLA 95 Workshop on Business Object Design and Implementation Springer Verlag 1995 16 Cockburn A Writing Effective Use Cases The Crystal Collection for Software Professionals Addison Wesley Professional Boston 2000 17 Cockburn A Surviving Object Oriented Projects A Manger s Guide Addison Wesley Longman 1998 18 Coad P LeVebvre E De Luca J Java Modeling In Color With UML Enterprise Components and Process Prentice Hall 1999 19 Beck K Extreme Programming explainend Embrace change Addison Wesley 1999 20 Theunissen W H Derrick G Standards and Agile Software Development SAICSIT 2003 Johannesburg September 2003 21 Forward A Lethbridge T C The Relevance of Software Documentation Tools and Technologies A Survey ACM Symposium on Document Engineering 2002 pp 26 33 22
232. imes and Rates Number of Weeks prior number 1 _1 Abb 5 3 Weekly Activity Summary Das Vorgehen ist auch f r die Folgewochen gleich allerdings kommen Informationen dazu die helfen die durchschnittliche maximale und minimale Arbeitszeit pro Aufgabenfeld zu ermitteln Diese Werte werden in der Abbildung 5 4 festgehalten Durch diese Informa tionen k nnen f r kommende Wochen f llige hn liche Arbeiten zeitm ig gut eingesch tzt werden Abb 5 4 Weekly Activity Summary II 125 159 5 1 4 Produktpl ne Der Hauptunterschied zwischen Periodenpl nen und Produktpl nen liegt darin dass sich Produktpl ne auf die Dauer die ein Produkt bis zur Fertigstellung ben tigt bezieht und nicht die Ar beiten auflistet die innerhalb einer Periode gemacht werden Ein Produktplan sollte ber die vermutete Gr e ber die ben tigte Zeit und den Verlauf des Projektes Auskunft geben damit ein wohl definiertes und schlie lich zuverl ssiges Endprodukt gew hrleistet werden kann F r gr ere Produkte empfiehlt es sich die Arbeit in kleinere Jobs aufzuteilen da solche leichter zu planen sind und folglich solche Pl ne auch leichter eingehal ten werden k nnen Wie wird nun ein Produktplan verwendet um seine Arbeit sinnvoll zu sch tzen Wenn man wei dass in dieser Woche eine hnliche Aufgabe z B eine Pro grammieraufgabe anf llt wie in einer der Vorwochen so kann man aufgrund der vorhergegang
233. immung des Dokumentes sollte betreffend Gebrauch von Terminologie und hnlicher Funktionalit t si chergestellt sein z B der Button Close muss in allen teilen des Systems gleich ausschauen Modifizierbarkeit Das Dokument sollte in ei ner zusammenh ngenden Weise organisiert sein da es so einfacher zu ndern und zu verwenden ist Z B sollten Inhaltsverzeichnisse einen Hy perlink auf den Teil im Dokument beinhalten Nachvollziehbarkeit Sie muss zwischen hn lichen Dokumenten garantiert werden Das hei t dass die Nachvollziehbarkeit r ckw rts zur Quelle sichergestellt sein muss genauso wie vorw rts zum Design und zum Code Eindeutigkeit Die Aussage ber die Anforde rungen sollte eindeutig sein das hei t die An forderung darf nicht in unterschiedlichen Wei sen zu deuten sein Eine Aussage sollte nicht mehr als eine Bedeutung haben Verifizierbarkeit Es sollte m glich sein die Anforderungen zu berpr fen dass hei t die Anforderungen m ssen erf llt werden Die An forderungen im Dokument sollten hingegen messbar sein Verwendbarkeit w hrend der Entwicklung des Betriebes und der Wartung des Systems Das Dokument sollte in der vollst ndigen Le bensdauer des Informationssystems verwendbar sein und bedeuten dass es in einer Weise ent worfen werden sollte die als Grundlage f r die Arbeit dienen kann welche w hrend der Ent wicklung der Betriebstechnik eines Informati onssystems erledigt wir
234. imulatoren ausprobieren lassen k n nen Denn das gr te Problem dabei ist dass die Auf traggeber Bodenpersonal dass das Geld zahlt wie etwa American Airlines oder die Chinesische Air Force hier nicht gleich den Endbenutzern Piloten sind Somit kann es passieren dass ein Pilot des Kun den einmal sagt Das fliegt sich nicht gut Und das ist ein Problem obwohl es immer noch der Auftraggeber ist der im Endeffekt das System akzeptiert oder nicht 7 Abnahmetests und Qualit t In diesem Kapitel versuche ich einen Zusammen hang zwischen dem Abnahmetest selbst und der Quali t t des gesamten Softwareproduktes herzustellen Dazu werde ich als erstes auf acht Qualit tsma st be einge hen die H Sneed in seinem Buch Software Qualit ts sicherung 16 als messbar qualifiziert und diese in Bezug mit dem Akzeptanztest setzen Zu den Qualit tsma en It 16 geh ren e funktionale Vollst ndigkeit Benutzerfreundlichkeit Effizienz Zuverl ssigkeit Sicherheit Wartbarkeit Erweiterbarkeit und bertragbarkeit Wie man auf den ersten Blick sehen kann wenn man Kapitel 2 aufmerksam gelesen hat stehen die ersten beiden Werte in unmittelbarem Zusammenhang mit dem Akzeptanztest Denn der Abnahmetest testet ja in erster Linie ob die Abnahmekriterien erf llt wurden und dazu geh rt nun einmal die vollst ndige Funktionalit t Test auf vertragliche Akzeptanz Und da der Test von den sp teren Benutzern durchge
235. ine Technik die gro teils auf praktischer Erfahrung von Managern beruht Dabei geht es nicht darum das Ziel einer Ver nderung festzulegen oder zu bewerten ob eine Ver nderung richtig oder falsch ist Ver nderungsmanagement kann man in jeder Situation bei jeder Ver nderung anwenden es interessiert sich f r den Prozess der Ver nderung selbst Dabei begr ndet es sich auf zwei grundlegende Ideen Einerseits der S Kurve andererseits dem Konzept des unfreezings Die S Kurve ist eine zweidimensionale Kurve die horizontale Achse stellt hier die Zeit dar und die vertikale Achse steht f r Leistung Profit und Zufriedenheit Nach der Einf hrung eines neuen Systems geht die Leistung anfangs etwas zur ck da 83 159 die Ver nderung den Arbeitsablauf st rt Dann steigt die Kurve allm hlich wenn sich die Vorteile der Ver nderung auswirken Schlie lich kommt es zu einer Stagnation oder sogar einem leichten Abfallen der Kurve da sich die Benutzer an die neue Situation gew hnen An diesem Punkt ist die Entwicklung abgeschlossen und die Organisation wird voraussichtlich die n chste Ver nderung in Angriff nehmen Ver nderungsmanagement versucht nun diese Kurve zu optimieren Der anf ngliche Verlust soll minimiert werden die Steigung soll so hoch hinauf wie m glich und der Verlust am Ende soll minimiert oder gar verhindert werden 6 Gevrinn Die zweite Sichtweise sagt dass Mitarbeiter zuerst aus ihren Gewohnheite
236. iner zuf lligen Reihenfolge bis zu 90 Einsparung an Stubs bringen Durch die Konstruktion pr ziser ORDs und einem optimalen Algorithmus zum Aufl sen von Zyklen kann der Testprozess zus tzlich verbessert werden 6 Referenzen 1 Ana Milanova Atanas Rountev and Barbara G Ryder Constructing Precise Object Relation Diagrams Proceedings of the International Conference on Software Maintenance October 2002 2 D Kung J Gao P Hsia Y Toyoshima and C Chen A test strategy for object oriented systems Proc of Computer Software and Applications Conference pp 239 244 IEEE Computer Society 1995 3 D Kung J Gao P Hsia Y Toyoshima and C Chen Class firewall regression testing and software maintenance of object oriented systems Journal of Object Oriented Programming pp 51 65 May 1995 4 Brian A Malloy Peter J Clarke and Errol L Lloyd A Parameterized Cost Model to Order Classes for Class based Testing of C Applications Proceedings of International Symposium on Software Reliability Engineering ISSRE 03 Denver Colorado November 17 20 2003 pages 353 364 5 L Briand Y Labiche Y Wang An Investigation of Graph Based Class Integration Test Order Strategies JEEE Transactions on Software Engineering vol 29 6 2003 6 Thierry J ron Jean Marc J z quel Yves Le Traon and Pierre Morel Efficient Strategies for Integration and Regression Testing of OO Systems Pro
237. ines Systems zu charakterisieren kann man den Zeitpunkt in dem der Benutzer die Kontrolle hat als Zustand beschreiben Diese Zust nde lassen sich nun gemeinsam mit den Aktionen des Computers und den berg ngen zwischen Zust nden 77 159 und Aktionen zu einem Diagramm zusammenfassen Denert 4 spricht hier von Schematischen Interaktionsdiagrammen Ausgehend von Zust nden in denen der Computer wartet wird durch bet tigen einer virtuellen Taste ein Zustands bergang zu einer Aktion ausgel st wenn diese erledigt ist gelangt das System wieder in einen Zustand Als virtuelle Taste wird jede Aktion des Benutzers gesehen sei es nun eine Taste des Keyboards ein Button eine Men auswahl oder ein Kommando Grunds tzlich sollte das Verhalten eines Programms dem Ablauf entsprechen in dem Benutzer ihre Arbeit erledigen durch den Computer hinzukommende Aspekte sollten den Benutzer nicht behindern Jeder Benutzer hat bestimmte Erfahrungen wie bestimmte immer wieder auftauchende Aktionen ablaufen beispielhaft hierf r w re nicht nur wo man ein Dokument speichern kann sondern auch wie viele Klicks dazu n tig sind Ein Programm sollte dar ber hinaus f r den Benutzer steuerbar sein er muss die Geschwindigkeit des Arbeitsablaufs und die Reihenfolge der Aktivit ten beeinflussen k nnen 1 Im Rahmen des Verhaltens eines Systems von Bedeutung ist die Navigation Die Navigation beginnt bei einem System bei einem bestimmte
238. ines existierenden Systems nach sich ziehen kann 4 3 STEP 3 Entwickle den Akzeptanztestplan Der erste Schritt zu effektiver Softwareakzeptanz ist die Entwicklung eines Akzeptanztestplans allgemeiner Projektpl ne und vertraglicher Anforderungen um sicherzustellen dass die Anforderungen der s Anwen der s korrekt repr sentiert und auch ganz abgedeckt werden Der Akzeptanztestplan bringt eine bersicht ber die T tigkeiten w hrend des Akzeptanztests und soll daf r sorgen dass die Ressourcen daf r auch im Pro jektplan enthalten sind Allerdings kann der Plan w h rend der Entwicklung noch erg nzt werden und muss nicht von Anfang an schon alle Details enthalten Im Akzeptanztestplan enthalten sein sollten 4 3 1 Projektbeschreibung Typ des Systems Le benszyklusmethodik Benutzergemeinde des geliefer ten Systems die Hauptaufgaben des fertigen Systems externes Interface des Systems erwarteter normaler Gebrauch potentieller Missbrauch Risiken Bedin gungen Standards und Praktiken 4 3 2 Benutzerverantwortlichkeiten Organisation und Verantwortlichkeiten f r die Akzeptanzaktivit ten Ressourcen und Zeitplanung Annehmlichkeits anforderungen Anforderungen f r automatischen Sup port spezielle Daten Standards Konventionen Updates und Reviews des Akzeptanzplans und verwandter Produkte 4 3 3 Administration Anomalieberichte nderungs kontrollen Kommunikation zwischen Entwickler und Managementorganisa
239. inger sind die Kosten f r dessen Korrektur Beispielsweise kann ein schwerer Fehler im Anforderungsdokument wenn er erst in der Integrationsphase erkannt wird sehr hohe Kosten oder im ung nstigsten Fall das komplette Redesign des Produktes zur Folge haben Das prim re Ziel ist es also diese Fehler m glichst fr hzeitig zu erkennen und zu beheben Reviews sind Methoden der Qualit tssicherung die w hrend des gesamten Entwicklungsprozesses zum Einsatz kommen Sie beschr nken sich in diesem Prozess nicht auf einen bestimmten Abschnitt daher k nnen sie bereits in der Analyse und Designphase als auch w hrend der Entwurfs und Implementierungphase zur Fehlerfindung eingesetzt werden Au erdem sind Reviews nicht nur auf die Softwareentwicklung beschr nkt im Gegenteil sie haben sich bereits in nahezu allen technischen Prozessen bew hrt 2 1 Ziele und Ergebnisse eines Reviews Ein Review hat das generelle Ziel Probleme in den Artefakten des Software Prozesses aufzudecken Es geht also den Fragen nach Erf llt das gepr fte Ergebnis seinen Zweck Wird das Produkt den Unterlagen entsprechen Sind die Merkmale des Produkts die Geforderten Die Hauptziele eines Reviews stellen das Entdecken von Fehlern das Eingrenzen von Folgekosten die Behebung von Qualit ts schwankungen und das berpr fen ob das Dokument sich an gewisse Standards h lt da Nebenbei hat ein Review aber auch eine ganze Reihe positiver Nebeneffekt
240. insatz von XP gesehen beziehungsweise als Projektmana gementumgebung f r XP 3 2 2 Feature Driven Development Feature Driven Development wurde von John de Luca und Peter Coad 18 begr ndet Dieser agile An satz deckt nicht den gesamten Softwareentwicklungs prozess ab sondern konzentriert sich auf die Design und Entwicklungsphase Feature Driven Development wurde aber so ausgelegt dass es mit andern Software entwicklungsprozessen zusammenarbeiten kann Der Prozess ist so einfach wie m glich gehalten Ausge hend von einem Modell wird eine Featureliste erstellt Anhand dieser Liste werden diese Features geplant und anschlie end in einem iterativen Prozess entwickelt Die Summe der Features f hrt schlie lich zu dem gesamtem Produkt In den Iterationsphasen gibt es neben dem Unittesting als Qualit tssicherungsma nahme auch eine Code Inspektion Die Rollenvertei lung des Feature Driven Development wei t eine Tes terrolle aus Diese kann von einem Einzelnen oder von einem Team eingenommen werden Des Weiteren gibt es eine Rolle f r die Dokumentation 4 Traditionelle SE Unterschiede zur agi len SE Die Idee der traditionellen Softwareentwicklung ist im Wesentlichen an der Vorgehensweise anderer In genieurswissenschaften wie zum Beispiel dem Bauwe sen 2 angelehnt Der Schaffensphase geht eine Pla nungsphase voran das hei t es wird zuerst anhand von Modellen das zu fertig stellende Produkt geplant und anhand dies
241. ischen Bauteilen und software gesteuerten Komponenten wurde das Fortbewegungsmittel zum Arbeitsplatz zur Freizeitbesch ftigung und zum Hobby Das Fahrzeug von heute beinhaltet inzwischen mehr Software SW als man denken k nnte In den aktuellen Mittelklassewagen geh ren Extras wie Klimaanlage oder Tempomat zur Grundausstattung die durch eigens entwickelte Computerprogramme gesteuert werden und bei einem Neukauf eines Autos kaum noch wegzudenken sind Navigationssysteme Einparkhilfen ABS controlling und vieles mehr ist f r den rasanten Fortschritt und die Beliebtheit moderner Fahrzeuge verantwortlichtt vorausgesetzt diese funktionieren Zelle ze m Au arme a ch Nalnmamn 01 07 200 Um einen berblick ber die Entstehungsgeschichte der eingebetteten Softwaresysteme im Auto zu geben soll die nachfolgende Abbildung dienen in der einerseits ersichtlich ist welche Elektronik wann ihren Ursprung hatte und andererseits wie umfangreich der Einsatz dieser mit der Zeit wurde Die Entwicklung der Elektronik Software ACC Stoparco BFD ALC KSG Navigationssystem Voll CD Wechsler Internet Portal ACC Active Crouse GPRS UMTS A Control A ElektronischeGetriebe Airbags Online Sp SKEDE DSC Dynamic Stability urbe Elektronische Control A pate Kuimaregelume Adaptive Getriebesewerung 7 i Local Hazard Warring De ee Mic ney Sty Sen ER ABS Anti Blockier System on ieh ER Geschwindiwkeitsregler T
242. ispiel von Internetprojekten Gerade anhand dieses Beispieles wird offensichtlich dass hier die bertrie bene Plantreue eher dem Projekt hinderlich ist und eine Zuwendung hin zu einer leichtgewichtigen Form der Qualit tssicherung gefunden werden muss Zu sammenfassend kann gesagt werden dass die agile Softwareentwicklung eine alternative zu den traditio nellen Ans tzen sein kann Die Qualit t hingegen h ngt von der Durchf hrung des Prozesses ab 8 References 1 Cockburn A Agile Software Development Addison Wesely Boston 2001 2 Fowler M The New Methodology http www martinfowler com articles newMethodogy html Besucht am 12 April 2004 37 159 3 Royce W W Managing the Development of Large Software Systems Proceedings of IEEE WESCON August 1970 4 Boehm B Guidelines for verifying and validating software requirements and design specification Euro IFIP 1979 pp 711 719 5 Boehm B A Spiral Model of Software Development and Enhancement ACM SIGSOFT Software Engineering Notes August 1986 6 Beck K Embracing Change with Extreme Programming IEEE Computer 32 10 pp 70 77 7 Beck K Extreme programming explainend Embrace change Addison Wesely Boston 1999 8 Abrahamsson P Salo O Rankainen J Warsta J Agile software development methods Review and analysis VTT Electronics 2002 9 Agile Alliance http www agilealliance com Besucht am 12 April 2004 10 Ag
243. it Difficulty D n 2 Na na und schlie lich den Aufwand Effort E D V Bei Halstead s Metriken gehen die Meinungen ber deren N tzlichkeit weit auseinander 11 Praktische Relevanz erlangten diese Metriken im Bereich der Softwarewartung als Teil der Maintainability Index Technique for Measuring Program Maintainability 11 12 3 Objektorientierte Metriken Auch wenn sich die traditionellen Softwaremetriken auf objektorientierte Software anwenden lassen so nehmen sie doch in keiner Weise Riicksicht auf die spezifischen Merkmale der Objektoriertierung Aus diesem Grund wurden und werden viele neue OO Metriken entworfen die dem objektorientierten Paradigma besser gerecht werden 3 1 Koh sion Koh sions Metriken versuchen Aufschlu ber die Zusammengeh rigkeit der zu einer Klassen zusammengefa ten Attribute und Methoden zu 5Operatoren sind nicht nur mathematische Operatoren sondern je nach Programmiersprache auch andere Symbole wie Indizes oder Trennzeichen wie 14 geben Diese Metriken analysieren jede Klasse einzeln Bei der Messung der Koh sion gibt es grunds tzlich zwei verschiedene Zugangsweisen Man versucht entweder die Koh sion direkt zu messen oder einen m glichen Mangel an Koh sion Lack of Cohesion festzustellen 3 1 1 Lack of Cohesion in Methods Chidamber und Kemerer leisteten mit vielen ihrer Metriken wesentliche Vorarbeit im Bereich der OO Metriken Unter
244. it tsstandards Um das Risiko der Projektgef hrdung zu minimieren gewinnen Zertifizierungen aus einer Reihe von Gr nden eine besondere Bedeutung Zum einen sind die einer Zertifizierung zu Grunde liegenden Kriterien sehr gute Checklisten um den eigenen Reifegrad gezielt entwickeln und berpr fen zu k nnen Zum anderen k nnen offizielle Zertifizierungen als Dokumentation eines Reifegrads nach au en Kunden oder interne Auftraggeber verwendet werden Nicht zuletzt hat eine offizielle Zertifizierung aber auch den Effekt dass die f r einen Reifegrad notwendigen Ma nahmen z B Kostenkontrolle tats chlich eingef hrt werden wenn sie f r einen externen Auditor unabh ngig berpr ft werden Neben den ISO9000 gewinnt das amerikanische Capability Maturity Model CMM der Standard des SEI weltweit eine immer st rkere Bedeutung CMM wird oftmals als Zertifizierungsstandard verwendet Unsere Organisation hat CMM Level 3 es kann aber ebenso als Checkliste verwendet werden um herauszufinden was eine erfolgreiche und effektive Softwareorganisation auszeichnet 4 CMM CMM ist ein Modell das beschreibt wie sich Praktiken des Software Engineering in Organisationen unter bestimmten Bedingungen entwickeln e Die Arbeitsschritte werden als Prozess organisiert und betrachtet e Die Entwicklung des Prozesses wird systematisch geleitet 2 Der Softwareprozess ist eine Menge von Werkzeugen Methoden und Praktiken die wi
245. it will ein Gutachter eigentlich aus dem Extended Abstract auf m glichst knappem Raum ausreichend klar erkennen wie das ganze Werk denn ausschauen wird Dieses Ziel der Gutachter wird sicherlich NICHT erreichbar sein wenn Autoren selbst noch nicht ausreichend klar ist wo er denn landen wird sich das Extended Abstract auf ein Motivationskapitel Zusammenfassungskapitel irgendeinen Ausschnitt beschr nkt oder durch andere Formen der Unausgewogenheit einen unbeabsichtigt falschen Eindruck vermittelt Ich hoffe dass Sie in Ihrer Vorbereitung diesen Zielen recht nahe kommen und in der Begutachtung hoffentlich auch Extended Abstracts sehen werden die diesen Vorstellungen einigerma en gut entsprechen Zum Schluss ein Wort des Trostes Ich denke ein gutes Extended Abstract zu schreiben geh rt wohl zu den schwierigsten Aufgaben im wissenschaftlichen Publikationsprozess Aber Sie haben ja auch entsprechend Zeit daf r Herzliche Gr e Roland Mittermeir 157 159 7 30 7 50 8 20 8 40 9 10 9 30 7 45 8 10 8 40 9 10 9 35 Anhang 4 Seminar aus Angewandter Informatik Sommersemester 2004 R Mittermeir Programm der 1 Vortragsrunde 25 Mai 2004 SR 2 42 Thomas FRANK Testen komponenten basierter Software Stefan PERAUER Robert SORSCHAG Effektives Testen objektorientierter Software mit Objekt Relations Diagrammen Daniela INNERWINKLER Gunar M TZLER Mutationentest Objektorientierte
246. itischer SW ist es zunehmend wichtig die Qualit t dieser zu gew hrleisten um die Fahrzeuginsassen nicht in Gefahrensituationen zu bringen bzw sie aus solchen Zust nden wieder herausholen zu k nnen Die serienm ige Herstellung von Automobilen mit software und elektronisch gesteuerten Elementen erfordert eine optimale Funktionsweise dieser Bestandteile um das Risiko eines eventuell lebensbedrohlichen Versagens zu minimieren 3 1 Qualit tsmerkmale Aufgrund der leider immer wieder auftretenden Fehlfunktionen im PKW kristallisierten sich die wichtigsten Qualit tsmerkmale und Anforderungen an die Software heraus Markante zu erf llende funktionale Eigenschaften sind nicht nur in der Automobilbranche die Zuverl ssigkeit Verf gbarkeit Sicherheit Funktionserf llung Leistung sprich die F higkeit von schwachen Prozessoren viel ausf hren zu k nnen Reaktionszeit bez glich der Echtzeiteinfl sse Benutzerfreundlichkeit Wartungsfreundlichkeit bertragbarkeit die an das SW Gesamtprodukt gestellt werden um ein Versagen so gut es geht zu unterbinden Software ist allerdings ein immaterielles und nicht physikalisches Produkt wie es der Rest des Automobils ist und so mag es zun chst den Anschein haben dass durch die schnelle Modifikation ein Vorteil entsteht Dies kann sich aber rasch ins Negative wenden wenn z B kurzfristige nderungen vorgenommen werden m ssen und so ebenfalls eine gesamte nderung
247. ity Engineering YEEE November 1998 pp 11 121 150 Zeitmanagement im individuellen Softwareentwicklungsprozess unter spezieller Ber cksichtigung schulischer Aspekte Katharina Fritz 0060308 kfritz edu uni klu ac at Abstract In dieser Arbeit n hern wir uns dem Thema Zeitmanagement im individuellen Softwareent wicklungsprozess sowohl von theoretischer als auch praktischer Seite und erl utern wie Zeitmanagement in der Schule und im Beruf funktionieren k nnte Als erstes ist es nat rlich n tig sich mit den Begriffen individueller Softwareentwicklungsprozess und Zeitmanagement auseinanderzusetzen Ziel hierbei ist es zu thematisieren warum durch eine ge naue Sch tzung des Entwicklungsaufwands der ein zelnen Phasen des Softwareentwicklungsprozesses und der daraus resultierenden Zeitplanung qualitativ hoch wertige Software entstehen kann In weiterer Folge konzentrieren wir uns auf das Zeitmanagement wobei Methoden vorgestellt werden wie man die ben tigte Zeit f r einzelne Prozesse in Projekten eruieren beziehungsweise sch tzen kann Die Tauglichkeit dieser Techniken wird an schlie end sowohl f r den Bereich der professionellen Softwareentwicklung als auch den schulischen Bereich analysiert 1 Einleitung Nur ein sorgf ltig geplantes Softwareprojekt wird gute Ergebnisse erzielen Deshalb ist es wichtig im Rahmen des Studiums und auch schon in der Schule Techniken des Zeitmanagem
248. k cazSzhomepageszSzgradszSzcab130zSz856zS ztrace pdf kenny96requirements pdf 11 A Finkelstein Tracing Back from Requirements in IEE 1991 Tools and Techniques for Maintaining Traceabi lity During Design IEE Colloquium Computing and Control Division Professional Group C1 Digest No 1991 180 pp 7 1 7 2 12 K Pohl PRO ART Enabling Requirements Pre Traceability RWTH Aachen Informatik V 1995 13 A Dahlsted Requirements Engineering Chaper 11 Department of Computer Science University of Sk vde Quelle http www ida his se ida kurser informationsystems_enginee ring kursmaterial forelasningar Chapter1 1_2003 pdf 14 B Ramesh T Powers C Stubbs M Edward Imple menting Requirements Traceability A Case Study In Proc of the IEEE Int Symposium On Requirements Engineering RE 95 York UK March 1995 pp 89 95 15 Quelle http www computerware com dl reqtrace pdf 75 159 Spannungen zwischen Benutzergewohnheiten und neuer Bedienbarkeit Werner S hs 9855851 wsuehs edu uni klu ac at Abstract Die Gewohnheiten eines Benutzers werden ber Jahre der Arbeit mit Computern und Programmen hinweg gepr gt Es entsteht eine Fixierung auf die Art und Weise wie ein gewohntes Programm seine Arbeit erledigt und zu bedienen ist Wird nun ein Wechsel des Programms vorgenommen sei es aus technischen Gr nden weil das bisherige Programm neuen Anforderungen nicht gerecht wird o
249. kation bringt ein Groupware Tool Bereits dokumentiertes Wissen wird durch das Abspeichern in allgemein zug nglichen Dokumenten ver ffentlicht Das erm glicht interessierten Mitarbeitern auch in Themengebiete Einblick zu bekommen die sie nicht direkt betreffen Dies bildet ein quivalent f r informelle Kommunikation ber Teamgrenzen hinweg Weiters bieten diese Tools die Verwendung von Foren an die als Diskussionsplattformen genutzt werden k nnen Dieses Tool verbindet alle Mitarbeiter egal ob sie in gleichen oder verschiedenen Projektteams arbeiten und bietet allen die selben Informationsm glichkeiten 4 Konclusio Die Requirements Engineering Phase hat in globalen Projekten mit zus tzlichen Herausforderungen zu k mpfen Einige L sungsans tze wurden im vorigen Abschnitt vorgestellt Vorschl ge wie an die L sung des Wissensmanagementproblems herangegangen werden soll sind noch nicht dokumentiert F r manches wie die Zeitverschiebung und die kulturellen Unterschiede gibt es keine L sung sondern nur mehr oder weniger effiziente Methoden mit den Gegebenheiten umzugehen Der Requirements Engineering Prozess eines globalen Projektes erfordert ein besonderes Fingerspitzengef hl Viele Schwierigkeiten die in jedem Projekt auftreten werden versch rft wie z b Kommunikationsprobleme und Wissensmanagement 104 159 Andere Probleme treten zus tzlich auf wie die Zeitverschiebung und die kulturellen Unterschiede D
250. keiten zwischen den Klassen Dadurch greifen traditionelle Testmethoden der prozeduralen Programmierung nicht bei welchen die Komponenten erst einzeln getestet und anschlie end in das Gesamtsystem integriert werden Bei objektorientierter Software werden als kleinste Test Einheit die Klassen angesehen Allerdings k nnen Klassen aufgrund der Abh ngigkeiten untereinander nicht gesondert getestet werden Ein objektorientiertes System als Ganzes zu testen wirft wiederum andere Probleme auf Eine fehlerhafte Klasse kann andere Klassen destabilisieren Der Fehler kann dann oft nicht mehr lokalisiert werden Ein anderes negatives Beispiel w ren mehrere fehlerhafte Klassen die zuf llig ein richtiges Verhalten zeigen Deshalb wird beim Testen ein inkrementeller Ansatz bevorzugt Zuerst werden Klassen getestet die nicht von anderen Klassen abh ngen Im n chsten Schritt testet man die Klassen die von schon getesten Klassen abh ngen Um eine Klasse zu testen die von ungetesteten Klassen abh ngt muss zus tzlicher Aufwand betrieben werden Ungetestete Klassen werden dabei durch Stubs simuliert Da diese manuell erstellt werden will man die Anzahl der n tigen Stubs minimieren Daher ist die Testreihenfolge der Klassen wichtig erst Klasse A testen dann Klasse B etc Schon getestete Klassen m ssen nicht durch einen Stub simuliert werden Um eine Testreihenfolge zu finden bieten sich Graphen an die Klassen und ihre Abh ngigkeiten dar
251. kt und besonders auch f r Softwareentwick lungsprojekte ist Insbesondere bei solchen Projekten f llt die richtige Sch tzung oft schwer da viele oft unvorhersehbare Faktoren hier mitspielen und der Fortschritt und Erfolg von K nnen und Kreativit t der Programmierer abh ngig ist Dennoch sollte trotz der Vielzahl an Unsicherheiten nicht auf eine Aufwands sch tzung verzichtet werden Diese Sch tzung ist so wohl zu Beginn durchzuf hren als auch regelm ig w hrend des Entwicklungsprozesses um Abweichun gen vorzeitig zu erkennen und Gegenma nahmen und Korrekturen einzuleiten In dieser Arbeit wurde COCOMO II als algorithmi sche Methode zur Aufwandssch tzung schrittweise mit seinen drei Submodellen Application Composition Model Early Design Model und Post Architecture Model und deren jeweiligen Formeln pr sentiert Auch wurden die Entwicklung des Modells und die Unterschiede zu COCOMO 81 dargelegt Zum Ab schluss wurde das Modell kritisch betrachtet seine Einsatzgebiete erl utert und sowohl kostenlose als auch kommerzielle Tools zur Erleichterung der Be rechnung vorgestellt Literatur BOEH81 B W Boehm Software Engineering Economics Prentice Hall Englewood Cliffs 1981 BOEH00 B W Boehm et al Software cost estimation with COCOMO II Prentice Hall PTR Upper Saddle River 2000 KNOE91 H D Kn ll Aufwandssch tzung von Software Projekten in der Praxis Bibliographisches Institut amp F A Brockhaus A
252. kzeug zu geben um die von ihm gestellten Anforderungen in Testf lle umzusetzen Um diese Anforderungen zu erf llen k nnen vier Testtypen f r die agile Softwareentwicklung als relevant betrachtet werden 22 welche im Folgenden betrachtet werden sollen 6 1 Akzeptanztest Das Ziel der Akzeptanztest ist es die Erf llung der Kundenanforderung zu pr fen Akzeptanztests werden so wie das sp ter erw hnte By Hand Testing vom Kunden ausgef hrt Wesentlich bei Akzeptanztests ist dass der Kunde keine unmittelbare Kenntnis ber die eingesetzte Softwaretechnik besitzen muss Anhand der von ihm erwartenden Funktionalit t spezifiziert der Kunde die Testf lle und f hrt diese aus Die Durch f hrung der Tests h ngt dabei von dem Wissenstands des Kunden ab deshalb steht den meisten Kunden bei der Spezifizierung und Durchf hrung der Tests ein Tester zur Seite Akzeptanztests werden fortlaufend durchgef hrt das hei t je nach eingesetzter Methode wird innerhalb der Entwicklungsphase fortlaufend mittels Akzeptanztest gepr ft ob die Anforderungen des jeweiligen Iterationsschrittes erf llt werden Da der Kunde im Besitz des Akzeptanztests ist obliegt es alleine dem Kunden zu bewerten ob der Akzeptanztests erfolgreich absolviert wurde Bei Scheitern des Testes wird dem Kunden das Testproto koll zur Kontrolle vorgelegt Die Erf llung des Ak zeptanztests ist wesentlich f r die Entscheidung ob der n chste Prozessschritt ausgef hrt w
253. l AT amp T 3 Das folgende Beispiel stammt von AT amp T Das Ziel der Entwickler war es die Effektivit t ihrer Software Inspektionen zu evaluieren Die Hauptaufgabe war die Kosten Nutzen Analyse der Inspektionen Die GQM Methode wurde hierbei genutzt um die zutreffendsten Metriken f r die Analyse festzustellen siehe Tabelle 2 Tabelle 2 AT amp T Goals Questions and Metriken Goals Questions Metriken Planung Wie viel kostet Aufwand pro KLOC der Inspektions x i prozess der Reinspektionen Wieviel Zeit be Aufwand pro KLOC n tigt der Inspek tionsprozess Anzahl der KLOC die inspiziert wurden Beobach Wie hoch ist die Anzahl an Fehlern pro tung und Qualit t der inspi KLOC Kontrolle zierten Software Inspektionsrate Vorbereitungsrate Mitarbeiterzu Inspektionsrate spruch zu den Vorbereitungsrate Prozeduren LOC die inspiziert wurden der Reinspektionen Wie ist der Status Anzahl der KLOC die des Inspektions inspiziert wurden Prozesses Verbesse Wie effektiv ist Defektentfernungseffi rung der Inspektions zienz prozess Anzahl an Fehlern pro KLOC Inspektionsrate Vorbereitungsrate 110 159 LOC die inspiziert wurden Aufwand pro gefun denem Fehler Wie ist die Pro duktivit t des Inspektionspro zesses Inspektionsrate Vorbereitungsrate LOC die Inspiziert wurden Nachdem die Entwickler die relevanten Metriken identifiziert hatten gingen sie daran
254. l Zeit und Geld kosten k nnen Das deswegen weil solche Fehler wenn sie erst in sp teren Phasen des Entwicklungszyklus entdeckt werden im schlechtesten Fall bei der bernahme durch den Kunden sich durch alle vorherigen Phasen ziehen k nnen und damit den Nachbesserungsaufwand oft deutlich vergr ern Das Hauptziel von Reviews und Inspektionen ist die Fehlerfindung in Softwareprodukten Um dieses Ziel zu erreichen sind Methoden notwendig die es erlauben strukturiert und kontrolliert nach Fehlern zu suchen Lesetechniken sind ein Ansatz um die Effizienz und Effektivit t der Fehlerfindung in Softwaredokumenten zu erh hen Eine M glichkeit um die Ergebnisse einer Inspektion zu verwalten zu archivieren und zu analysieren stellt LIDS da Allerdings ist dieses Tool nicht sehr bedienungsfreundlich und basiert auf eine Software die im Handel nicht mehr erh ltlich ist Die Erstellung eines dementsprechend modernen Tools zur Unterst tzung des Reviewprozesses und dessen Auswertung w hre daher eine sinnvolle Weiterentwicklung im Bereich der Qualit tssicherung 6 Referenzen Biffl 2001 Biffl Stefan Software Inspection Techniques to support Project and Quality Management Shaker Verlag 2001 Download http home att net rge com lids lids htm Fagan 1976 Fagan M E Design and Code Inspections to Reduce Errors in Program Development 1976 IBM System Journal IEEE 1990 IEEE Standard Glossary of Sof
255. l an skalierbaren und projektbegleitenden Ser vices die auf die branchenspezifischen Bed rfnisse der Unternehmen zugeschnitten werden Diese Firma wirbt mit Slogans wie Uberlassen Sie das Testen nicht Ihren Kunden Kosten Zeit und Risiko minimieren und hnliches Die Software Quality Systems AG f hrt Tests darunter auch Anwendungstests Funktionstests Systemtests auf allen Ebenen des Software Entwicklungsprozesses durch Dabei wird die Testum gebung nach spezifischen Erfordernissen des Kunden ist in diesem Fall der Entwickler aufgebaut Nach dem erfolgreichen Test im TestLab der SQS wird das Teilsystem auf Wunsch ausgeliefert in der Umgebung des Benutzers implementiert und die Mitarbeiter in der Durchf hrung der Wiederholungstests angeleitet Da mit k nnen in Zukunft anstehende Wartungstests in einer praxiserprobten Testumgebung selbst ndig durchgef hrt werden Nach eigenen Angaben ist SQS der f hrende Dienstleister f r Software Testen und Software Qualit tsmanagement in Europa Basierend auf rund 20 Jahren Projekterfahrung setzt die SQS Gruppe Standards f r Methoden und Techno logien des Software Testens und Qualit tsmanage ments Ihre Leistungen decken Bereiche wie die Gro rechnerwelt Client Server Anwendungen und auch Internet L sungen ab SQS ist auch eines der gr ten Schulungsunter nehmen f r SW Testen und SW Qualit tsmanagement in Europa und h lt immer wieder Seminare Workshops und
256. lange sie nur die Fehlerdaten ber cksichtigen oder Metriken die gesammelt wurden wenn keine Testdaten vorhanden sind Da sie die Software als eine Einheit sehen bezeichnet man sie als Black Box Einige wichtige Begriffe auf diesem Gebiet seien kurz aufgelistet Die einzelnen Modelle zu pr sentieren w rde den Rahmen dieser Arbeit sprengen 119 159 Tabelle 1 Terminologie Begriff Erl uterung M t Die gesamte Anzahl von Fehlern zum Zeitpunkt t u t Durchschnittswert fiir SRGM Repr sentiert die erwarteten Fehler zum Zeitpunkt t A t Fehler Intensitat abgeleitet von der Durchschnittswert Funktion Z At t Risiko Rate der Software Die Wahrscheinlichkeitsdichte des i ten Fehlers N Initiale Anzahl von Fehlern vor dem Testen 4 2 2 White Box Software Reliability Models Man betrachtet die interne Struktur um Absch tzungen treffen zu k nnen Die Behauptung existiert dass Black Box Testing nicht ad quate ist im Bereich Component Based Software Bef rworter von White Box Models behaupten sogar um einiges realistischere Sch tzungen damit durchf hren zu k nnen Der Weg wie solche Modelle benutzt werden l sst sich in folgende drei Klassen einteilen Pfadbasierte Zustandsbasierte und Additive Modelle 4 3 Annahmen vs Realit t 1 In der Entwicklung von Software Reliability Growth Models werden gewisse Annahmen getroffen Der Grund daf r liegt auf der Hand Einerseits versucht man die R
257. le 1 Unterschiede agile und traditionelle SE 5 eXtreme Programming In den vorangegangen Kapitel wurde eXtreme Pro gramming bereits als Ausl ser f r die Entstehung der agilen Softwareentwicklung genannt Extreme Pro gramming XP wurde von Kent Beck 19 Ward Cunningham und Ron Jeffries begr ndet XP wurde als Antwort zu den bestehenden Problemen des tradi tionellen Ansatzes entwickelt und setzte sich als der bekannteste Vertreter der agilen Methoden durch Im Wesentlichen ist XP eine Sammlung von Ideen und Praktiken wobei durch die extreme Anwendung dieser Methoden der Technik der Name verliehen wurde 5 1 Der Lifecycle von XP Der Prozess von XP besteht aus f nf Phasen Ex ploration Planning Iterations to Release Production izing Maintenance und Death EXPLORATION PLANNING ITERATIONS TO PHASE PHASE RELEASE PHASE CONTINUOUS REVIEW DEATH PHASE a Emon Tom wo FEEDBACK r Priorities um SN 7 es FON So Abbildung 1 Lifecycle XP Prozess 8 Im Folgenden werden die einzelnen Phasen n her beschrieben 8 In der Exploration Phase werden die gew nsch ten Anforderungen anhand so genannter Storycards erfasst Diese Storycards werden vom Kunden ausge f llt und beinhalten die Funktionalit t der gew nschten Software Das Projektteam macht sich zwischen zeitlich mit den verwendeten Tools und Software praktiken vertraut und baut damit einen ersten Proto typen des zu entwickelnden Sy
258. le einer Diplomarbeit h tte Vorteile scheint doch f r die Mehrheit der Studierenden das in dieser Veranstaltungsform gegebene studentische Feedback eine wichtige Orientierungshilfe zu sein Die relativ freie Themenwahl ist motivierend hat jed och auch ihre Gefahren auf die Lehrveranstaltungslei tungen vorbereitet sein sollten Man mag fragen ob man die damit verbundenen Risken in einer Pflichtlehrveran staltung eingehen m chte Das Argument dass dies f r jene Studierenden die mit dem Bakkalaureat abschlie en die letzte einzige Chance im Studium ist in Eigenver antwortung eine kleine wissenschaftliche Arbeit zu ver suchen sollte dabei ber cksichtigt werden Bei etwas geringerer aber stabilerer Teilnehmerzahl sollte es auch m glich sein den in als Konferenzseminar organisierten Spezialseminaren erzielten intensiven Dis kurs zu den Pr sentationen in das Bakkalaureatsseminar zu bertragen sodass auch dieser Aspekt der Vorinfor Interessant mag unter diesem Aspekt ein Vergleich von 6la UniStG 99 mit seiner Referenz auf 61 2 freie Wahl des Diplomarbeitsthemas mit 80 UG 2002 sein Dieser verweist nicht mehr auf 81 Diplomarbeiten Dieser deutet jedoch in Abs 2 eine Festlegung des Themas durch den Betreuer an oder l sst allenfalls offen wer die Aufgabenstellung so w hlt dass die Bearbeitungsfrist eingehalten werden kann Es wird wohl am Selbstverst ndnis der Universit ten und ihrer Angeh rigen
259. ler nicht von seiner Verantwortung ent bunden 2 Akzeptanztests verlieren ihren Wert nicht auch wenn der Kunde das System als implementiert abge nommen hat Sie sind weiterhin erforderlich um sicherzustellen dass weitere nderungen am System bereits vorhandene Funktonalit t nicht modifiziert haben somit erh ht sich die Qualit t nachfolgender Tests Au erdem spart man dadurch Zeit und Geld 5 Es gibt die verschiedensten Einteilungen von Ak zeptanztests Laut Spillner 6 wird der Abnahmetest in den Test auf vertragliche Akzeptanz in 7 Produkti ons Abnahmetest in den Test auf Benutzerakzeptanz in 7 funktionaler Abnahmetest und in den Feldtest unterteilt wobei er letzteren noch einmal in Alpha Test und Beta Test aufteilt Norman Parrington 8 und Edward Kit 9 hingegen unter scheiden generell nur zwischen Alpha Test und Beta Test Ich verwende hier die Einteilung von Spillner 6 2 1 Test auf vertragliche Akzeptanz Hierbei priift der Kunde ob die vorliegende Soft ware den Vertrag beziiglich der dort vereinbarten Systemeigenschaften erf llt Es wird also die Software auf M ngel aus Kundensicht untersucht Um hier eine definierte Entscheidungsbasis zu haben m ssen die Abnahmekriterien zuvor klar und pr zise im Vertrag definiert worden sein Bevor der Hersteller die fertige Software dem Kunden zur Abnahme vorlegt sollte allerdings der Systemtest im eigenen Haus schon ge zei
260. levanz und Notwendigkeit von Requirements Tra ceability veranschaulichen You can t manage what you can t trace und Requirements Traceability can help in managing change and cost for all types of pro jects 1 Wie dieser Arbeit zu entnehmen ist wird der Requi rements Traceability Mythos als t glicher lebens wichtiger Betrieb angesehen da der Mechanismus des Tracings die Aufgaben der Life Cycle Wartung enorm erleichtert und hilft Prozesswissen in SW Entwicklungsorganisationen zu erzeugen speichern konsistent zu halten sie aufzubereiten und immer ver f gbar zu halten Auf Grund der Arten des RT wurde veranschaulicht wo die Probleme liegen und wie diese verbessert werden k nnen Die Einf hrung eines erfolgreichen Requirements Traceability in einer Organisation ist eine gro e Her ausforderung Die Gr nde daf r sind zahlreich ver schiedene Sichtweisen Modelle Zwecke Qualit tsatt ribute und ihre Abh ngigkeiten der Anforderungen untereinander Wie schon erw hnt wurde ist RT eine leistungsf hige Methode die eine Datensammlung unterst tzt die genau auf die Ziele einer Organisation ausgerichtet ist Diese Arbeit soll aufzeigen dass der Einsatz von RT in einer Organisation sinnvoll ist Referenzen 1 0 C Z Gotel and A C W Finkelstein An Analysis of the Requirements Traceability Problem Proceedings of the First International Conference on Requirements Engineering IEEE Colorado Sprin
261. lge war Das geschlossene Vorziehen der reinen Seminaristen ergab sich rein daraus dass diese doch weniger umfangreiche Arbeiten auszuarbeiten hatten Hier wurde auch noch in Ans tzen eine thematische Gruppierung vorgenommen Bei den Bakkalaureats arbeiten wurde die Vortragsreihenfolge eher nach Kriterien des Stands der Erstausarbeitungen getroffen sodass an den jeweiligen Tagen sowohl Studierende mit guten Zwischenleistungen als auch Studierende mit Verbesserungsbedarf der Erstfassung der Bakka laureatsarbeit pr sentierten In Abw gung der Quali t tsverbesserungen der meisten zur zweiten Kategorie geh renden Arbeiten scheint dieses Konzept aufge gangen zu sein 6 Studentisches Feedback Gegen Ende der Veranstaltung wurde den Studieren den ein Fragebogen zur Verf gung gestellt der in ge schlossenen Fragen die Relation von Ertrag zu Aufwand dieser Veranstaltung bzw Veranstaltungsform erhob und dar ber hinaus drei Felder f r Freitext zur Frage was hat mir gefallen und was hat mir nicht gefallen erhob Die Befragung wurde von 7 von 8 Bakkalaureats studierenden und von 8 von 16 Seminaristen beantwortet Eine Person f llte die Charakterisierung Bakkalaureat oder normales Seminar nicht aus Dies bedeutet 10 Stu dierende also etwa ein Drittel der Studierenden beteilig ten sich an dieser Befragung nicht Im Durchschnitt hatten die Befragten vor dieser Ver anstaltung 3 9 Proseminare und 1 8 Seminare besucht Dabei
262. lines of code und in weiterer Folge in KSLOC umgerechnet werden Diese Standardtabellen geben die Anzahl der 53 159 SLOC pro Function Point f r jede Programmierspra che an Tabelle 2 gibt hier die Werte f r eine Auswahl der wichtigsten Programmiersprachen an BOEH00 Der Exponent E soll den steigenden Aufwand bei wachsender Projektgr e ausdr cken Der Wert ist hier nicht genau festgelegt sondern kann zwischen 1 01 und 1 26 liegen Abh ngig ist die Gr e dieser Zahl von der Neuartigkeit des Projekts der Entwick lungsflexibilit t den verwendeten Prozessen zur Risi kol sung dem Teamzusammenhalt und der Ausge reiftheit des Prozesses BOEH00 Zur Berechnung des Exponenten werden nun die f nf Skalierungsfaktoren siehe Tabelle 3 nach einer Sechs Punkte Skala 5 sehr gering bis 0 besonders hoch bewertet Die Ergebnisse werden addiert durch hundert dividiert und zum fixen Wert 1 01 hinzuge z hlt Tabelle 3 Skalierungsfaktoren f r den Exponenten PREX Personnel Experience die Erfahrung des Personals FCIL Facilities die unterst tzenden Einrichtungen SCED Required Development Schedule der Zeitplan Auch diese Faktoren werden mittels einer Skala siehe Tabelle 4 bewertet Multipliziert man die Er gebnisse gelangt man zum Multiplikator M Tabelle 4 Projekt und Prozessfaktoren RCPX 0 49 0 60 0 83 1 33 1 91 2 72 RUSE 0
263. listische Anforderungen k nnen die Software Zuverl ssigkeit negativ beeinflussen 1 Nach der Auslieferung des Produktes kann man die Zufriedenheit der Kunden von deren Reaktion ablesen Problemberichte Komplimente und Beschwerden sind Indikatoren der Selbigen Doch ist es zu diesem Zeitpunkt schon zu sp t Software Hersteller ben tigen diese Informationen fr her bevor sie den Kunden betreffen Software Reliability Growth Models k nnen helfen diese Informationen zu beschaffen Alle Fehler Verbleibende Fehler Entdeckte Fehler Anzahl Fehler Testzeit Abbildung 1 Verbleibende Fehler 3 Das Software Release Management Software ist wichtiger geworden f r den Erfolg eines Unternehmens 3 Die anwachsende Nachfrage an Software hat einen Wettstreit zwischen den H ndlern ausbrechen lassen Der Mangel an disziplinierten und vorhersehbaren Software Praktiken ist einer der Hauptgr nde f r die berschreitung der Kosten in Software Projekten 3 In naher Vergangenheit hat die Industrie auf Grund wachsender Konkurrenz damit angefangen die Kundenzufriedenheit zu messen und nutzt deren Input f r Produkt Entwicklungen und Erweiterungen 118 159 Die Zuverl ssigkeit von Software Systemen muss analysiert werden Das zuk nftige Fehlerverhalten ist vorhersehbar indem man das vergangene Fehlerverhalten studiert und modelliert 2 Analysten im Software Business betonen die Tragweite de
264. lle des Moderators und ist verantwortlich f r den organisatorischen Ablauf Einf hrung Tutorial Neue Teammitglieder oder Teams die mit der Methode nicht vertraut sind lernen die Grundregeln und Techniken der Inspektion Diese optionale Einf hrung kann einerseits zum Verst ndnis der Methode und andererseits zum besseren Verst ndnis der An wendungsdom ne oder des Inspektionsartefakts eingesetzt werden Vorbereitungsphase Preparation Phase In einem Zeitraum von ungef hr zwei Stunden bei hoher Komplexit t kann die Vorbereitungsphase umfangreicher sein bereiten die Inspektoren die n tigen Hilfsmittel vor die sie sp ter f r die Inspektion brauchen Das prim re Ziel dieser Phase ist die Einarbeitung in den Anwendungs bereich und die Auseinandersetzung mit Inspektionen Ausf hrung Operation Unter der Leitung des Moderators inspiziert das Team das Softwareprodukt Auch bei der Inspektion ist die Fehlerfindung das Hauptziel Alle Fehler werden dokumentiert und dabei nach Typ Schwere Auswirkung usw katalogisiert Dabei geht es nicht um m gliche Verbesserungen oder Korrekturen sondern nur um die Erfassung der Fehler Die subjektive Entscheidung ber die Verwendbarkeit des Dokumentes d h ob eine berarbeitung notwendig ist oder das Dokument freigegeben werden kann beendet die Ausf hrungsphase e berarbeitung Rework Basierend auf den notierten M ngeln berarbeitet der Autor das inspizierte Dokument e
265. llten sie es Software Firmen erm glichen selbst Metriken im Rahmen eines Projektes einer klar definierten Validierung zu unterziehen 5 2 Druckmittel Metrik Der zweite Kritikpunkt betrifft weniger die Metriken an sich als vielmehr die Art und Weise wie sie verwendet werden bzw verwendet werden k nnten Mit dem Thema wie Metriken in einem Unternehmen benutzt werden um Druck auf die Mitarbeiter auszu ben hat sich Tom DeMarco in seinem Artikel Mad About Measurement 5 ausfiihrlich beschaftigt Er zeigt anhand von realen Beispielen innerhalb und au erhalb der Software Industrie wie sich Arbeiter und Angestellte dazu veranlasst sehen k nnen die Metriken an denen sie gemessen werden zu umgehen DeMarco nennt dies eine Dysfunktion Diese tritt ein sobald Mitarbeiter Energie darauf verwenden die Metrik zu ihrem eigenen Vorteil zu beeinflussen ohne dabei die urspr ngliche Intention mit der die Metrik eingef hrt wurde etwa Effizienzsteigerung Qualit tssteigerung zu verfolgen So kann durch den Einsatz einer Metrik sogar die Qualit t sinken Keine der in dieser Arbeit angef hrten Metriken ist darauf ausgelegt un berlistbar zu sein Die Annahme der Autoren dieser Metriken ist dass die Softwareentwickler daran interessiert sind gute Arbeit zu liefern und nicht Metriken zu manipulieren Selbst wenn es eine Metrik g be die zB unverf lschlich die Qualit t einer Software quantifizieren k nnte w re sie wahrscheinl
266. loren Diese Information ist aber gerade beim Ausarbeiten von Kompromissen wichtig was einen nicht unwesentlichen Teil der Requirements Engineering Phase ausmacht Eine weitere Erschwernis ist die Planung der Kommunikation Spontane oder zuf llige Treffen sind bei globalen Projekten unm glich Wenn ein Problem auftaucht muss erst ein Termin gesucht werden was durch die Zeitverschiebung siehe Abschnitt 2 3 noch zus tzlich verkompliziert wird Die M glichkeit den Partner sofort aufzusuchen um das Problem zu l sen besteht nicht Bei Projekten mit gro er Zeitverschiebung wenn keine gemeinsamen B rostunden vorhanden sind ist sogar mit einem Werktag Verz gerung zu rechnen Somit verl ngert sich die Requirements Engineering Phase die oft auch 102 159 bei lokalen Projekten als zu zeitaufwendig empfunden wird Eine zus tzliche Kommunikationsbarriere ist die Fremdheit der einzelnen Personen untereinander Wenn Unsicherheiten auftauchen ist die Hemmschwelle bei unbekannten Personen nachzufragen h her Au erdem besteht auch die Gefahr dass nicht bekannt ist welche Person aus dem anderen Team mit dem Gebiet betraut ist Damian gibt in ihrer Arbeit 5 zu bedenken dass die Entfernung auch gewisse Ressentiments st rken kann Wenn keine Teambildung ber die Grenzen hinweg erfolgt besteht gro e Gefahr dass jedes Team versucht f r sich selbst die beste L sung zu finden statt die beste L sung f r das Projekt zu suchen
267. m glich w re hat Jerry Gao 2 untersucht Die systematische Ver waltung der Test Informationen ist der grundlegende Schritt in Richtung Testautomatisierung Standards m ssen f r alle Bereiche des Testens festgelegt wer den Ebenso muss auf Portabilit t und Kompatibilit t geachtet werden um mit verschiedenen Plattformen und Sprachen arbeiten zu k nnen Wichtig ist hier die Frage wie wiederverwendbare und konfigurierbare Testtreiber und Teststubs f r eine Komponente gene riert werden k nnen Testtreiber m ssen skriptbasierte Programme sein die auf Basis von Funktionen oder Szenarien arbeiten Zur automatischen Durchf hrung der Tests ist eine Umgebung n tig die drei wichtige Bereiche umfasst e Ein Komponenten Testcontroller der aus einer Testsuite die Testskripts generiert die Ergebnis berpr ft und Berichte erstellt e Ein Komponenten Test Stub Manager der aus ei nem Test Stub Controller einer Schnittstelle zu ei nem Test Stub Repository und einem Generator f r Test Stubs besteht e Eine Testumgebung die die Interaktion der Kom ponenten mit dem Komponenten Testcontroller und dem Test Stub Manager unterst tzt Plattformunabh ngige Technologien wie Java werden vorgeschlagen um eine solche generische Black Box Test Umgebung zu bauen Angaben in wieweit solche Versuche der Automatisierung bereits realisiert wurden macht Gao nicht 2 4 4 Testen ohne Sourcecode Eine der wesentlichen Einschr nkungen beim
268. ment e techniken spezifische Themen wie etwa o Requirements Elicitation Requirements Feedback Requirements Tracing spezifische Review Techniken spezifische Test Verfahren Aspekte der Software Integration im Zusammenhang mit CBSE o Software Metriken und ihr Bezug zu Qualit t e sonstige Themen mit Fokussierung auf Software Qualit t 00000 Bitte beachten Sie dass gleichviel f r welche Themengruppe sie sich entscheiden und unab h ngig von Ihrer Zuordnung zu einer der vier studentischen Kategorien eine klar fokussierte Arbeit erwartet wird Stecken Sie sich daher kein zu breites Thema W hlen Sie vielmehr einen Bereich in dem Sie sich vertiefen wollen und zu dem Sie Aussagen aus der Literatur reflektierend kommentieren oder an eigenen Erfahrungen messen Seminararbeiten Bakkalaureatsarbeiten erst recht sind kleine eigenst ndige wissenschaftliche Arbeiten die in der jeweils relevanten Fachliteratur wurzeln und in eigenst ndigen Beitr gen 154 159 gipfeln Damit solche Gipfel auch erreichbar sind d rfen sie nicht zu breit angelegt werden Anderseits muss die Basis nat rlich breit genug und ausreichend tragf hig sein Keinesfalls sind Seminar Bakkalaureatsarbeiten nett vorgetragene Nacherz hlungen Lehrziel ist dass Studierende durch selbst ndige Bearbeitung eines aktuellen Themas aus Ange wandter Betriebs Informatik neben fachlichen Kenntnissen auch methodische Kenntnisse im Verfassen wissenschaftlicher Arbeiten etw
269. ms Information and Software Technology http www elsevier com locate infsof December 2003 4 Martin R OO Design Quality Metrics An Analysis of Dependencies http www objectmentor com publications oodmetrc pdf October 1994 5 Tom DeMarco Why Does Software Cost So Much Essay 2 Mad About Measurement Dorset House Publishing 1995 6 Zuse Horst History of Software Measurement http irb cs tu berlin de zuse metrics 3 hist html 7 Wheeler David A SLOCCount http www dwheeler com sloccount 8 Jeff Nyman Code http www globaltester com sp6 codemetrics html Metrics 9 Morris Metrics for Object Oriented Software Development Environments Master s Thesis M I T Sloan School of Management 1989 10 VanDoren Edmond Cyclomatic Complexity http www sei cmu edu str descriptions cyclomatic html 11 VanDoren Halstead Complexity Measures http www sei cmu edu str descriptions halstead html Edmond 12 VanDoren Edmond Maintainability Index Technique for Measuring Program Maintainability 13 Sencer S Software Measurement Page Object Oriented Metrics http yunus hun edu tr sencer oom html 14 Sencer S Complexity Metrics and Models http yunus hun edu tr sencer complexity html 15 Cain Andrew JMetric Home http www it swin edu au projects jmetric products jmetric Page
270. mt Die vorgeschlagenen LCOM Varianten werden von ihren Autoren nat rlich plausibel erl utert und ihre Vorteile gegen ber zumindest einer anderen LCOM Metriken aufgezeigt Aber aufgrund der Plausibilit t alleine ist ein objektiver Vergleich bzgl ihrer Praxistauglichkeit nicht m glich Auf dieses Problem der Validierung von Metriken wird in Kapitel 5 1 noch n her eingegangen 60 159 3 1 2 Loose Class Cohesion Tight Class Cohesion Einen anderen Weg bei der Messung von Koh sion verfolgen Bieman und King Zun chst unterscheiden sie zwischen direktem und indirektem Zugriff auf Variablen Ein direkter Zugriff ist gegeben wenn in einer Methode unmittelbar eine Variable ausgelesen oder beschrieben wird Bei einem indirekten Zugriff wird lediglich eine andere Methode aufgerufen die auf die Variable direkt oder indirekt zugreift Aus diesen direkten und indirekten Zugriffen werden die Metriken Tight Class Cohesion TCC und Loose Class Cohesion LCC berechnet TCC ist der Prozentsatz an Methodenpaare die direkt oder indirekt auf zumindest ein gemeinsames Attribut zugreifen Es ist hier auch von direkten Verbindungen zwischen den Methoden die Rede Bei LCC werden auch indirekte transitive Verbindungen ber cksichtigt 3 2 Komplexit t Einer Anwendung der Cyclomatic Complexity Metrik auf Objekt steht im Grunde nichts entgegen Folgende zwei Varianten des Einsatzes in der OO Welt bieten sich an 3 2 1 Weighted Meth
271. muss Wenn der K ufer die Unterst tzung des Verk ufers zur Durchf hrung des Akzeptanztests oder zur L sung von Problemen in dieser Phase ben tigt sollte dies im Softwareentwicklungsplan durch einen Zeit und Ressourcenplan reflektiert werden Die Priorit ten f r Probleme und akzeptable Antwortzeiten f r die ver schiedenen Kategorien sollten identifiziert und im Ver trag festgehalten werden Die Akzeptanzkriterien des K ufers sollte als Deli verables des K ufers in den Vertrag aufgenommen werden Der Verk ufer sowie auch der K ufer sollten sich beide bewusst sein dass ein sich entwickelndes Set von Akzeptanzkriterien egal ob basierend auf Evolving Requirements oder auf einem wachsenden Verst ndnis des K ufers gegen ber dem Produkt das Budget zum Explodieren bringen kann Das K ufer und Verk ufer Management sollten diesen Teil des gesamten Plans und Prozesses aufgrund der Auswir kung die er auf das Budget den Zeitplan und das K ufer Verk ufer Verh ltnis haben kann im Auge behalten 3 2 Akzeptanztestplan Der Akzeptanztestplan sollte am Beginn der Akzep tanztestphase aufgestellt werden und folgende Punkte enthalten Zeitplan Evaluierungsvorgang Soft Hardware Umgebung und Ressourcen Akzeptanzkriterium Bei der Identifikation dieser Punkte sollte der Ver k ufer dem K ufer assistieren Der Grad dieser Hilfeleistung kann stark variieren Tats chlich kann und wird oftmals auch alles in dies
272. n Einstiegspunkt Im westlichen Kulturkreis wird anf ngliche Information zuerst links oben gesucht im Arabischen und Asiatischen rechts oben Die Navigation sollte durch Gruppierung der Elemente und klare Grenzen vereinfacht werden Des Weiteren sollte auch die Navigation per Tastatur Tabulator Taste unterst tzt werden 1 Um die Benutzer mit Informationen ber die Aktivit ten des interaktiven Systems zu versorgen werden sie konstant mit Feedback versorgt Dem Benutzer sollten st ndig seine bisher getroffenen Entscheidungen sowie deren Auswirkungen ersichtlich sein Feedback zur Verf gbarkeit kann durch Markierung oder Ausblendung von Elementen geliefert werden die Verf gbarkeit des ganzen Systems kann mit einer Sanduhr oder einem Fortschrittsbalken verbildlicht werden Textuelles Feedback sollte klar verst ndlich und h flich sein des weiteren ist es f r den Benutzer n tzlicher bei einer Fehleingabe zu erfahren was er besser machen kann anstatt zu erfahren was er falsch gemacht hat 2 2 Psychologische Faktoren F r die Entwicklung eines Programms ist es lebenswichtig die Erwartungen der Benutzer richtig einzusch tzen selbst f r den Fall dass das Programm auf anonyme Benutzer abzielt Diese Erwartungen k nnen Bearbeitungsreihenfolge von Prozessen Toleranz bei Wartezeiten strukturierten Entwurf Verst ndlichkeit Konformit t mit hnlichen Programmen und vieles mehr umfassen Auch negative Erwartungen sind
273. n Weltweite vernetzte Systeme Verteilung mit Datenkonsistenz E Business L sungen und vieles mehr sind Schlagworte die Wirklichkeit werden sollen Mit den Visionen wachsen auch die Anspr che an die Softwareentwicklung Anspr che denen der Projektalltag oftmals nicht gewachsen ist Projektabbr che und Zeit berschreitungen kosten meist viel Geld Oft wird die gew nschte Funktionalit t 89 159 nicht erreicht Immer noch scheitern ca 30 der Projekte und im Schnitt werden Projekte doppelt so teuer wie veranschlagt Dies kostet nicht nur Geld sondern bedeutet auch verlorenen Chancen im Gesch ft In der Zwischenzeit sehen die Banken das Projektrisiko als ein Risiko an das mit Eigenkapital zu hinterlegen ist Erfolgreiche Softwareorganisationen managen effektiv ihr Softwarerisiko Zeit Kosten und Qualit t werden so kontrolliert dass Projekte im Zeit und Kostenrahmen die gew nschte Funktionalit t liefern Dies minimiert das Projektrisiko Dar ber hinaus k nnen Softwareorganisationen die das Risiko ihrer Projekte effektiv managen die vorhandenen Informationen zu einer Verbesserung innerhalb der Projekte und der Softwareorganisation nutzen Es gibt wohl kein Unternehmen das keine erfolgreiche und effektive Softwareorganisation m chte Dennoch erreichen in der Praxis nur wenige Unternehmen dieses Ziel Erfolgreiche Softwareorganisationen m ssen gezielt gestaltet werden 3 Zertifizierungen zur Dokumentation von Qual
274. n die Aufmerksamkeit binden sollen sind Icons f r den Benutzer n tzlich und inhaltlich sinnvoll Das in einem Icon verwendete Bild muss wie es f r ein Piktogramm blich ist f r alle Benutzer verst ndlich sein Unterschieden werden Icons in hnlichkeitsicons Bild analog zu Bedeutung Exemplarische Icons typisches Beispiel Symbolische Icons Abstraktion auf h herer Ebene und beliebige Icon ohne Assoziation Die Software Ergonomie besch ftigt sich mit dem menschen bzw aufgabengerechten Design des Mensch Computer Dialogs Software Ergonomie befasst sich mit der Analyse Gestaltung und Bewertung der Arbeit des Menschen an oder mit rechnergest tzten dialogf higen Systemen soweit diese durch die Software bestimmt sind mit dem Ziel einer menschengerechten Gestaltung des Arbeitsmittels Diese erst seit ca 20 Jahren existierende interdisziplin re Fachdisziplin gr ndet sich zum gro en Teil auf Erkenntnisse der Psychologie Physiologie Arbeitswissenschaften Informatik bzw Grafikdesign 3 F r die benutzergerechte Anordnung von Bildelementen ist die Gestaltpsychologie bedeutsam die bildliche Szenen m glichst einfach interpretierbar darstellen will Nach dem Pr gnanzprinzip setzt sich immer eine Gliederung von Elementen durch die der menschlichen Neigung zu Einfachheit Symmetrie Regelhaftigkeit und Geschlossenheit entgegenkommt Kleine Figuren sind vor einem gro en Hintergrund schneller identifizie
275. n den Kunden ausgeliefert und die n chste Phase Maintenance beginnt Die Maintenance Phase zeichnet sich dadurch aus dass die Software bereits beim Kunden vor Ort im Einsatz ist f r etwaige nderungen werden wieder Iterationen 33 159 laut der Iterations to release Phase durchgef hrt wobei hier die Entwicklungszeiten k rzer werden Die Death Phase wird im XP Lifecycle dann erreicht wenn durch den Kunden keine weiteren Anforderun gen gestellt werden oder das System auf Grund von Fehlentwicklungen nicht mehr einsetzbar ist In diese Phase fallen auch die Dokumentation und die ber gabe an den Kunden 5 2 Das XP Team Wie bei allen agilen Methoden kommt auch bei XP dem Team eine besondere Bedeutung 19 zu Wobei dem Kunden innerhalb des Prozesses eine besondere Rolle zukommt Der Kunde ist sowohl f r das Verfas sen von den Anforderungen als auch f r die Erstellung von Testf llen zust ndig Zu diesem Zweck wird ihm innerhalb des Prozesses ein Tester zur Seite gestellt damit die Testf lle aufbereitet werden k nnen Diese Testf lle werden sowohl vom Kunden Tester und Programmierer ausgef hrt Der Kunden hat des Wei teren die Aufgabe den n chsten Implementierungs schritt zu bestimmen das hei t wie bereits erw hnt entscheidet der Kunde welche Anforderung im jewei ligen Iterationszyklus erf llt werden muss F r die Qualit tssicherung bedeutet dies dass Testf lle bezie hungsweise das Te
276. n f r diese Attribute dienen k nnen Softwarefirmen k nnen Softwaremetriken auf zumindest drei verschiedene Arten einsetzen 9 um Vorhersagen ber das System zu treffen um fr hzeitig Risikokomponenten zu iden tifizieren und zur Bestimmung von Design amp Programmier richtlinien Dies erlaubt es Unternehmen z B eine fr h zeitige Einsch tzung der Systemqualit t zu treffen und Ak tionen zu ergreifen um die Anzahl der fehlerhaften Soft warekomponenten zu verringern 1 1 Vorhersagen ber das System Normalerweise werden Softwaremetriken f r einzelne Kom ponenten eines einzelnen Systems gesammelt Vorhersagen ber die Einzelkomponenten k nnen jedoch vereinigt wer den um eine Vorhersage ber das gesamte System zu er Mario Lassnig 9961428 mario lassnig uni klu ac at m glichen So k nnen etwa Voraussagen ber die Fehler anf lligkeit jeder Klasse des Systems benutzt werden um daraus Schl sse ber die allgemeine Qualit t des Systems zu ziehen 1 2 Identifizierung von Risikokomponenten Die Definition einer Risikokomponente variiert abh ngig vom verwendeten Kontext M gliche Definitionen sind 9 eine Risikokomponente ist eine die irgendwelche Fehler enth lt die w hrend des Testens gefunden werden eine Risikokomponente ist eine deren Korrektur nach dem Auffinden eines Fehlers u erst kostenintensiv ist Wenn diese Komponenten fr hzeitig identifiziert werden ist das Unternehmen in der Lage vo
277. n gel st werden m ssen indem man sie mit dem gegenw rtigen Zustand unzufrieden und rastlos macht unfreeze dann m ssen sie nach vorne bewegt move und schlie lich an den neuen Zustand gew hnt werden refreeze Organisationen konzentrieren sich gew hnlich auf den mittleren Schritt und als Folge kehren die Benutzer fr her oder sp ter in ihre alten Gewohnheiten zur ck da ihnen die Motivation zur Ver nderung fehlt Dies setzt ver nderungsresistente Mitarbeiter voraus eine pessimistische Sichtweise die wohl genauso wenig zutrifft wie die vielfach geteilte optimistische Sichtweise dass Mitarbeiter den Enthusiasmus ihrer Manager teilen Die meisten Benutzer liegen irgendwo dazwischen und je nachdem wie ver nderungsresistent sie sind ist diese Methode von gro em Nutzen Funktionieren soll dies indem man den Mitarbeitern anfangs Gr nde f r die Ver nderung gibt das Gef hl dass sie die Ver nderung ausgel st und in der Hand haben Im Verlauf der Ver nderung muss den Mitarbeitern klar sein wieso sie genau den Weg gehen den sie gehen Und schlussendlich soll eine Stabilisierung durch Versorgung mit Erfolgserlebnissen folgen 6 Dokumentation ist als Teil der Benutzerschnittstelle zu betrachten und stellt oftmals den ersten Kontakt eines Benutzers mit dem System dar Sie dient dazu die intuitive Verst ndlichkeit eines Produkts zu erg nzen wo dieses zu komplex ist um sofort klar zu sein Nat rlich bleibt festzustellen
278. n in verschieden Programmiersprachen geschrieben wurden Ein weiteres Problem kann die Tatsache darstellen dass durch die M glichkeit des einfachen Plug and Play Dritte ihre Komponenten immer wieder updaten was jedes Mal Testaufwand erfordert Testf lle werden oft aus Spezifikationen abgeleitet welche neben dem Sourcecode ebenfalls nicht immer vorhanden sind 3 Begriffsbestimmungen Komponente Eine Komponente hat drei Hauptmerk male 1 eine Komponente ist ein unabh ngiger er setzbarer Teil eines Systems der eine eindeutige Funk tion erf llt 2 eine Komponente arbeitet im Kontext einer wohldefinierten Architektur 3 eine Komponente kommuniziert mit anderen Komponenten ber ihre Schnittstelle 3 Eine Komponente ist grunds tzlich ein bin rer Software Baustein man spricht hier meist von Commercial Off The Shelf COTS Komponen ten Oftmals werden Komponenten aber auch entwi ckelt um eine st rkere Modularisierung und damit bes sere Wartbarkeit von Anwendungen zu erreichen Test Treiber Test Stub Test Case Test Suite Test Treiber stellen einen Testrahmen zur Verf gung der den interaktiven Aufruf der zu testenden Dienste einer Systemkomponente erm glicht Test Stubs sind Platzhalter um noch nicht implementierte Systemkom ponenten zu simulieren Sie werden bei Integrations tests ben tigt Ein Test Case ist ein Satz von Testda ten der die vollst ndige Ausf hrung eines Pfades des zu testenden Programms initiert
279. nbezogen werden e Identifizierung des fertigen Produktes der Akzeptanzkriterien und des Zeitplans e Planung wie und von wem jede Aktivit t w hrend des Akzeptanztests ausgef hrt wird e Planung der Ressourcen um Informationen f r die Akzeptanzentscheidung zu sammeln e Ausreichend Zeit f r die sp teren Anwender zur Verf gung stellen damit sie das Produkt untersuchen und auswerten k nnen vorzugs weise vor dem Akzeptanztestreview e Vorbereitung des Akzeptanztestplans e Ausf hrung der endg ltigen Akzeptanztestak tivit ten bei der Auslieferung inklusive des formalen Akzeptanztests e Treffen der Akzeptanzentscheidung f r jedes Produkt Es besteht jedoch die M glichkeit einige Punkte an einen Akzeptanztestmanager abzutreten Dieser Mana ger kann ein Benutzer Entwickler oder auch eine dritte Partei sein 12 159 Develop Acceptance 4 2 STEP 2 Identifiziere die Abnahmekrite rien Der K ufer muss die Kriterien denen die Software entsprechen muss festlegen Idealerweise sind diese Kriterien in der Anforderungsspezifikation schon ent halten Als Vorbereitung zur Entwicklung der Akzep tanzkriterien sollte der K ufer e alles ber die Applikation f r die das System bestimmt ist wissen e die Risiken und Vorteile derjenigen Software entwicklungsmethode verstehen die zur Bil dung des Systems verwendet wird e die Konsequenzen verstehen die das Hinzu f gen von neuen Funktionen zur Verbesse rung e
280. nd Fehler meist leicht kontrollierbar durch Spezialisten e Level 1 Ablenkend ergibt funktionsbedingte Limitationen kann aber durch Benutzer kontrolliert werden Abschlie end folgt das Level 0 das jedoch eine reine Beeintr chtigung zur Folge hat Die auftretenden Fehler gef hrden die Sicherheit nicht hier steht lediglich die Kundenzufriedenheit im Mittelpunkt 43 159 51 G1 Al G2 2 G1 Risiko A2 G2 Al 3 A2 54 Safety Integrity Level SIL nach IEC 61508 Abbildung 3 Risikoanalyse zur Bestimmung der SIL 29 Risikoparameter S Schadensausma S1 leichte Verletzungen einer Person kleinere sch dliche Umwelteinfl sse S2 schwere irreversible Verletzungen einer oder mehrerer Personen oder Tod einer Person vor bergehende gr ere sch dliche Umwelteinfl sse S3 Tod mehrerer Personen lang andauernde gr ere sch dliche Umwelteinfl sse S4 katastrophale Auswirkungen sehr viele Tote A Aufenthaltsdauer Al selten bis fter A2 h ufig bis dauernd G Gefahrenabwendung G1 m glich unter bestimmten Bedingungen G2 kaum m glich W Eintrittswahrscheinlichkeit des unerw nschten Ereignisses Wil sehr gering W2 gering W3 relativ hoch Eine der wichtigsten Rollen in der Festlegung des Safety Integrity Levels bernimmt der Mensch Dieser hat den gr ten Einfluss ber die Software w hrend der Fahrt und liefert wichtige Faktoren f r die Sicherheitsanalyse die unbedingt miteinbezogen
281. nd aufgerufen sich zu berlegen welche inhaltlich technischen Voraussetzungen kundenseitig gegeben sind bevor man sich f r ein konkretes Prozessmodell entscheidet Brigitte GAUSTER geht in institutioneller Sicht einen Schritt in Richtung Kunde In der Arbeit Software im Automobil Qualitdtssicherung durch MISRA zeigt sie anhand des vielf ltigen Einsatzes von Software in modernen Kraftfahrzeugen dass eine gesamte Branche die Automobilindustrie branchenspezifische Standards entwickelte um die Ergebnisse von Eine Arbeit ber Remote Usability Testing von Web Applikationen erreichte leider nicht das f r Aufnahme in diesen Sammelband erforderliche Niveau 1 159 Forschungen zur Qualit tssicherung von life critical Software auf ihre speziellen Bed rfnisse zu adaptieren und so zu verbreiten Eine v llig andere Perspektive auf Qualit t nimmt eine zweite Gruppe von Arbeiten ein Ausgehend von der berlegung dass ein Kunde letztlich nur dann ein Produkt der gew n schten Qualit t geliefert bekommt wenn auch die zum Angebot f hrende Kalkulation korrekt war widmet sie sich der Aufwandssch tzung in fr hen Projektphasen sowie der begleitenden Aufwandskontrolle und verbesserten Sch tzung im Lauf des Projekts Daniela ESBERGER beginnt diese Gruppe mit der Arbeit Aufwandssch tzung am Beispiel COCOMO I Diese Arbeit wird durch den Aufsatz von Edmund URBANI Metriken zur statischen Analyse objektorientierten Source Codes kontrapunk
282. nde ersetzt 2 neue Applikation die eine bereits existente ersetzt 3 Wechsel der zugrunde liegenden Datenbank ohne nderung an der Applikation zB Upgrade von Oracle 7 3 auf 8 05 4 Erweiterung der bestehenden Applikation mit Funktionalit t 5 nderung der Funktionalit t der bestehenden Applikation und 6 nderung der Infrastruktur ohne nderung der Applikation zB neue Arbeitsumgebung neuer Server oder die Applikation wird auf einem neuen Gebiet eingesetzt Zur Entwicklung des Akzeptanztestplans wird ein 12 seitiges Template auf der Homepage zur Verf gung gestellt dass so umfangreich ist dass man beim Aus f llen einfach nichts vergessen kann Zus tzlich werden auf der Homepage noch detailliert Hinweise Hilfestellungen und Beispiele zum Ausf llen der Vor lage gegeben 6 4 Das WIKI WIKI Web Bevor ich zum Inhalt dieser Seite komme m chte ich kurz darauf eingehen wo der Name Wiki eigentlich herkommt beziehungsweise was das Wiki Web eigentlich ist 6 4 1 Hintergrund Das WikiWikiWeb ist eine Datenbank f r Entwurfsmuster die 1995 von Ward Cunningham entwickelt wurde Es bietet die M glich keit ohne HTML Kenntnisse mit Formularen Text zu editieren Da das auf diese Weise sehr schnell geht und au erdem auf diese Art eine Datenbank sehr schnell mit Daten angef llt werden kann ist der Name Wiki nahe liegend denn Wiki Wiki bedeutet schnell auf hawaiianisch Mittlerweile findet man viele solche
283. nden Methoden die diesem An satz zu zuordnen w ren sind zum Beispiel das Was serfallmodell 3 das V Modell 4 oder auch das Spi ralmodell 5 Des Weiteren werden traditionelle An s tze dadurch gekennzeichnet dass als Endergebnis jeder Phase ein Dokument entsteht Diese Dokumen tation dient zur berpr fung des Erfolges hinsichtlich der Planung und flie t in das Produkt zum Beispiel in Form von Handb chern ein Ein weiteres Kriterium der traditionellen Ans tze ist zumindest in den meisten Modellen dass bei Erkennen eines Fehlers nur durch vermehrten Aufwand dieser Behoben werden kann beziehungsweise ein R ckschritt in eine fr hre Phase auf Grund des Modells nicht gestattet ist 4 2 Probleme und Qualit tssicherung beim tra ditionellen Ansatz Wie Besprochen zeichnet sich der traditionelle An satz durch seine einzelnen Phasen aus Qualit tssiche rung ist hingegen ein Prozess der ber die gesamte Projektdauer betrieben wird Diese Eigenschaft macht es schwer Qualit tssicherung als eine einzelne Phase in den Prozess zu integrieren Durch die Einf hrung von Phasen mit einer abschlie enden Verifikations und Validationsphase wurde zumindest der Qualit ts sicherung insofern Rechnung getragen dass erst durch den erfolgreichen Abschluss dieser Phase die n chste begonnen werden kann Diese abschlie ende Phase ist in den einzelnen Methoden unterschiedlich realisiert eines aber haben alle Methoden gemein die Doku m
284. ndet Ich denke ob und vor allem wie Akzeptanztests wirklich ausgef hrt werden h ngt in erster Linie von der Gr e des Projektes ab Bei sehr kleinen Projekten wie etwa der Erstellung einer Kundendatenbank f r einen Kleinbetrieb arbeitet der Entwickler sehr stark mit dem Benutzer zusammen Dadurch kann der Be nutzer laufend pr fen inwiefern seine Anforderungen bereits erf llt sind und was noch fehlt Also entspricht hier der Abnahmetest eigentlich der Zusammenarbeit zwischen Entwicklerteam und Auftraggeber und der ganze Prozess kann eigentlich als Extreme Program ming aufgefasst werden Beispiele daf r w ren auch einige 4 h Praktika an der Uni Dadurch dass es hier regelm ige Meilensteine gibt die einzuhalten sind und bei denen jeweils auch s mtliche Anforderungen gepr ft werden gibt es hier keinen expliziten Akzep tanztest Vielmehr wird vom Projektbetreuer zum Schluss zwar alles noch einmal berpr ft aber ohne anfangs vereinbarten Testplan Handelt es sich jedoch um ein Gro projekt mit vielen Benutzern einem eigenen Akzeptanztestmana ger usw dann gibt es kein Entkommen Hier ist ein korrekt durchgef hrter Akzeptanztest unumg nglich um ein ordnungsgem es den Anforderungen entspre chendes und qualitativ hochwertiges Endprodukt zu erzeugen 9 References 1 Geoinformatik Lexikon der Universit t Rostock URL http www geoinformatik uni rostock de 2 Georg Erwin Thaller Software Qualit t
285. ndung der Major Defekte 3 5 Optimale Inspektionsrate Inspektionen sind dann am erfolgreichsten wenn die Inspektoren gr ndlich vorbereitet zur Sitzung kommen Ca 80 der Fehler die durch Reviews entdeckt werden k nnen finden die Gutachter schon in der Vorbereitungsphase In der eigentlichen Reviewsitzung werden also nur noch die restlichen 20 der Fehler gefunden Dies zeigt dass eine gr ndliche Vorbereitungsphase ein kritischer Erfolgsfaktor ist Tom 122 1M to 285 Inspection rate lines hour average errors found of 21 maximum known Abbildung 3 Die optimale Inspektionsrate SETE 2003 Es gibt Erfahrungswerte wie viel Zeit sich ein Reviewer fiir die Vorbereitung nehmen muss um die oben erw hnten 80 der Fehler finden zu k nnen Genau diese Erfahrungswerte dienen als Grundlage f r die optimale Inspektionsrate die f r Programme in der Regel eine Stunde f r 100 150 NLOCs non commentary lines of code vorsieht SETE 2003 Dies gilt ziemlich unabh ngig von der Programmiersprache F r Textdokumente ist diese Pr fgeschwindigkeit st rker abh ngig von der Art des zu pr fenden Dokuments Sie betr gt oft nur einige wenige Seiten pro Stunde und liegt bei extrem kritischen Dokumenten wie zum Beispiel bei den Anforderungsdefinitionen f r ein neues Flugzeug oder anderen technischen Produkten bei einer Seite pro Stunde oder sogar noch darunter 3 6 Lesetechniken Um die Effizienz eines Inspektionsteams zu
286. nen zumindest ein Strichpunkt vorkommt Zeilen die beispielsweise lediglich eine if Bedingung enthalten werden dadurch allerdings nicht 2Dies ist zum Beispiel beim in letzter Zeit immer mehr in Mode kommenden eXtreme Programming der Fall 3Wenn man LOC zur Messung der Leistung des Programmierers heranziehen will wovon der Autor im brigen abr t sollte man die Kommentarzeilen vielleicht doch mitwerten upwardflow downward flaw cyclomatic com plexity 7 essential campleity 1 design compledh 4 16 waitara Matrikan von NeCabe Abbildung 1 Kontrollflu graph eines einfachen Programms 10 gewertet 8 LOC ist in allen seinen Varianten sowohl auf prozedurale wie auch auf objektorientierte Programmiersprachen gleich gut bzw schlecht anwendbar Es ist allgemein bekannt da die Aussagekraft dieser Metrik eher gering ist aber aufgrund ihrer Einfachheit die eine sehr simple Implementierung erlaubt und die sie praktisch f r jedermann auch f r Nicht Informatiker durchschaubar macht ist diese Metrik bis heute nicht von der Bildfl che verschwunden Andere Metriken werden oft mit LOC verglichen weil als eine Grundanforderung f r neuere komplexere Metriken gilt da diese zumindest besser als das simple LOC sein m ssen 2 2 Cyclomatic Complexity Tom McCabe s Cyclomatic Complexity 1 gilt als eine der grundlegenden Metriken der strukturierten Programmierung Viele sp tere M
287. nen aber schon sehr viel fr her in der Entwicklung eingesetzt werden Dadurch werden die Qualit tsdefizite dort gefunden und beseitigt wo sie auch tats chlich entstehen Dies f hrt zu einer erheblichen Reduzierung der anfallenden Fehlerkosten 3 1 Arten von Inspektionen Die Fagan Formale Inspection ist die urspr ngliche Form einer Inspektion und bildet die Basis f r die meisten anderen Inspektionstechniken Das Active Design Review konzentriert sich wie der Name schon sagt haupts chlich auf Inspektionen eines Software Designs Die N Fold Inspektion zielt darauf ab eine Anzahl n kleiner Inspektionsteams einzusetzen die jeweils der Methode von Fagan folgen Der Grundgedanke geht davon aus dass kleine Gruppen h here Fehlerfindungsraten aufweisen als vergleichsweise gro e Gruppen Diese Methode wird von seinen Erfindern Martin und Tsai haupts chlich f r besonders kritische Projekte vorgeschlagen nachdem sie relativ kostenintensiv ist Martin Tsai 1990 Eine Mischform aus den bisher genannten Inspektionsarten ist die so genannte Phased Inspektion die von Knight und Myers entwickelt wurde Knight 1993 Dabei wird das Artefakt in mehreren Teilinspektionen untersucht die Phasen genannt werden Eine normale Inspektion kann bis zu 6 Phasen haben wobei jede Phase ein bestimmtes Ziel verfolgt Die Inspektoren untersuchen das Artefakt nur im Hinblick auf das jeweilige Ziel Solange das aktuelle Ziel nicht erreicht ist dah
288. nerseits durch die Z sur der Osterferien andererseits gepr gt Dies ergab einer seits dass die Zeit f r die Begutachtung der Lang fassungen sehr knapp war etwas mehr als eine Woche w re w nschenswert und dass f r die Pr sen tationsbl cke zu dem Zeitpunkt als sie geplant wer den konnten keine Termine f r Tages oder Halbtags bl cke mehr zur Verf gung standen Es w re jeden falls w nschenswert hier fr her planen zu k nnen und daher rechtzeitig also noch vor anderen Block lehrveranstaltungen etwa Pr sentations Samstage zu definieren Pr senzphase In den bisherigen Spezialseminaren war die Pr senzphase ein extramuraler Block in dem meist mehr als die Vortragszeit auf nachfolgende inhaltliche Diskussionen verwendet wurde Schlie lich ist durch den Begutachtungsprozess ja bei einem Teil des Auditoriums bereits ein hoher Bezug zum Referat vorhanden und diese rei en die anderen mit Wie erw hnt war dieser Effekt bei der hier gew hlten Form der zeitlich verteilten Pr sentation im Seminar raum nicht gegeben Die Begr ndung scheint jedoch im Zeitdruck gelegen zu sein der aufgrund der hohen Teilnehmerzahl entstand Wegen des erwarteten Teilnehmerschwunds konnte in diesem Fall nicht rechtzeitig ein Pr sentationsblock geplant werden sodass lediglich die Option des fr hen LV Beginns brig blieb Anzumerken ist noch dass die Vortragsreihenfolge nicht ident zur hier gew hlten Pr sentationsreihen fo
289. nes QM Systems befasste wurde berarbeitet und durch die neue Norm ISO 9004 Leit faden zur Leistungsverbesserung ersetzt Die Normen ISO 9000 3 Leitfaden f r Entwick lung Lieferung und Wartung von Software ISO 9004 2 Leitfaden f r Dienstleistungen und die ISO 9004 3 Leitfaden f r verfahrenstechnische Produkte sind entfallen Zusammenfassend ergibt sich folgender Aufbau ISO 9000 2000 Grundlagen und Begriffe ISO 9001 2000 Anforderungen ISO 9004 2000 Leitfaden zur Leistungsverbesserung ISO 19011 Leitfaden f r das Auditieren von Qualit tsmanagement und Umwelt systemen Durch diese nderung wurden die 25 Einzelnor men mit einem Umfang von 1000 Seiten auf vier Hauptnormen mit einem Umfang von ca 200 Seiten reduziert Sch 0l Seite 31 3 2 Prinzipien der neuen Version Im Zuge der Revision wurden acht Prinzipien f r das Qualit tsmanagement vorgestellt Sie stellen die Basis der Forderungen und des Aufbaus der neuen ISO 9000 Version dar Mit Hilfe dieser Prinzipien soll die 99 7159 Leistungsf higkeit eines Unternehmens verbessert werden 1 Kundenorientierung Ein Unternehmen ist haupts chlich von seinen Kunden abh ngig deshalb sollte die gesamte Unternehmensstruktur auf die Kun denbed rfnisse ausgerichtet sein W nsche und Bed rfnisse des Kunden m ssen verstanden und erf llt werden Es sollte danach gestrebt werden die Erwar tungen des Kunden zu bertreffen 2 F hrung Die F hrung
290. neuen Software Releases immer wichtiger fiir den Erfolg eines Software Unternehmens gemacht Um solch komplexe Entscheidungen treffen zu k nnen bedarf es einem gut durchdachten Software Release Management Hinsichtlich dessen werden wirtschaftliche Entscheidungsfindungen wie technische Durchsetzungsdetails beleuchtet Getrieben von vielen Studien auf diesem Gebiet besonders derma en vieler Modelle zur Zuverl ssigkeitsabsch tzung wird ein berblick geboten und die verschiedenen Gesichtspunkte bearbeitet 1 Einleitung Computer und die n tige Software zur Steuerung sind allgegenw rtig geworden in der unseren modernen Gesellschaft Die steigende Nachfrage treibt einen Wettkampf an zwischen immer f higeren Produkten und L sungen Um dabei die Zuverl ssigkeit nicht aus dem Blickwinkel zu verlieren geht das Augenmerk wieder mehr in Richtung Modellen zur Absch tzung von Fehlern Besonders wichtig ist dies f r life critical Software Die Arbeit ist wie folgt gegliedert Abschnitt 2 gibt einen motivativen Einstieg Es folgt ein wirtschaftlich forcierter Bereich ber das Software Release Management gefolgt von einem berblick ber Technische Modelle deren Annahmen und Umsetzungen Abschlie end werden einige Schlussfolgerungen gezogen die die Arbeit abrunden sollen 2 Motivation Die Entwicklung von zuverl ssiger Software ist eines der gr ten Probleme der Software Industrie Termindruck limitierte Ressourcen und unrea
291. ng vs Projektmanagement Requirements Traceability kann in der Projektver folgung und im Projektmanagement sehr sinnvoll und produktiv genutzt werden W hrend der Systemdefini tion und einzelnen Folgephasen gew hrleistet Tracea bility dass keine Systemanforderungen verloren gehen bzw alle eingehalten werden Die Projektmanager k nnten Verbindungen wie Status Vollst ndigkeit der Daten und Autorisierung zwischen verschiedenen Systembestandteilen f r die Terminplanung Fortbe stand und Sicherheit verwenden 4 1 5 Verantwortlichkeit Der Gro teil der Traceability verwendet tut dies um den Verantwortlichkeitsbereich zu verbessern Die Verwendung von Traceability legitimisiert beispiels weise die Kommunikation zwischen dem Designer einer Systemkomponente oder hilft beim Verst ndnis der Leistungsf higkeit Der Gebrauch von verantwort lichkeitsrelevanten Informationen als Mittel f r Leis tungsbewertung ist hier nicht angebracht 4 1 6 Humanware Humanware ist bei Projekten immer ein sehr kriti scher Bestandteil Es ist wichtiger denn je wie Hu manware und die Anforderungen an ein System in Verbindung stehen da es die Verantwortlichkeit f r eine Anforderung zu einer Person aufsp ren und mit einbeziehen kann Ein Beispiel f r so eine Verbindung w re die Systemfunktionalit t die ja von einer Person ausgef hrt wird bzw wurde 4 1 7 Dokumente und Handb cher Dokumenten Traceability beendet die Bezie
292. ng auf die Unterklassen da diese alle Variablen erben 4 1 2 Number of tramps NOT Die Bezeichnung von Methoden also deren Namen und alle Parameter mit denen sie aufgerufen werden stellen einen Hinweis auf die Komplexit t der Methoden dar da eine Methode mit vielen Parameter im allgemeinen schwieriger zu durchschauen ist als eine einfache Methode Die Metrik Anzahl der Methodenparameter ist als die Gesamtanzahl von allen Parametern aller Methoden der Klasse definiert 4 1 3 Violations of the Law of Demeter VOD Mit der Metrik Verst e gegen das Gesetz von Demeter hat die Aussage des Gesetzes von Demeter als Grundlage Das Gesetz von Demeter beschr nkt die Nachrichtenverbindun gen zwischen Klassen d h es versucht die Kopplung zu begrenzen Nachrichten eines Objektes sind nur erlaubt an sich selbst this Parameterobjekte Objekte die das Objekt erzeugt Komponentenobjekte Das Grundprinzip dahinter ist dass keine Nachrichten an Objekte geschickt werden sollen die R ckgabewerte anderer Operationen sind siehe 13 Das Ergebnis der Metrik ist die Anzahl der Methoden in der Klasse die gegen dieses Gesetz versto en 4 2 Metriken von Lorenz amp Kidd In 15 stellen Lorenz und Kidd eine Menge objektorien tierter Metriken vor Diese beziehen sich auf die Metho dengr e die Klassengr e die Klassenvererbung die Me thodenvererbung die internen Merkmale von Methoden die internen Merkmale von Klassen und
293. ng eines Call for Papers Beitr ge einreichen und diese von einem Programm komitee dem auch Studierende angeh ren begutachtet werden Dieses Begutachtungsverfahren liefert jedenfalls breites Feedback Das gilt sowohl f r jene deren Ar beiten akzeptiert werden als auch f r jene deren Arbei ten abzulehnen sind Aufgrund des Feedbacks aus dem Begutachtungsprozess k nnen die Einreichungen bzw die auf den schriftlichen Arbeiten fu enden Referate 145 159 berarbeitet werden Diese Referate finden nicht wie sonst in Seminaren blich laufend im Wochenrhythmus statt sondern in einem Block am Ende der Veranstaltung Um eine allf llige Ablehnung fr hzeitig zu erfahren wurde bisher stets ein zweistufiges Begutachtungsverfah ren eingesetzt Nach Einreichung eines m glichst aus sagekr ftigen Extended Abstracts siehe Seminarordnung Anhang 1 war die Vollversion der Arbeit zu verfassen die einer weiteren Begutachtung unterzogen wurde 3 Ausgangsbedingungen Die hier beschriebene Veranstaltung war urspr nglich als reines Bakkalaureatsseminar geplant Es stellte sich jedoch heraus dass die studentische Anfangspopulation die dieses Seminar besuchen wollte aus 23 Bakkalau reatsstudierenden der Informatik 28 Diplomstudierenden 3 Lehramtskandidatinnen und 14 Betriebswirtschafts studierenden bestand Da dies weit ber die f r ein Seminar zutr gliche Zahl von Studierenden hinausging und auch qualitativ aufgrund der un
294. ng f hren Ein berma an Details wirkt verwirrend und verhindert dass ein konzeptuelles Modell des Systems entwickelt wird Ist der Benutzer ber einen l ngeren Zeitraum nicht in der Lage die ihm gestellten Aufgaben zu erledigen kommt es zu Frustration Diese Probleme k nnen die Arbeitsleistung reduzieren oder sogar zu einer Nutzungsverweigerung f hren 1 1 2 Ein einleitendes Beispiel Vor etwa 20 Jahren filmte ein Forscher mit versteckter Kamera f hrende Xerox PARC Computerwissenschaftler beim Versuch das neue Kopierger t zu benutzen Das Ergebnis Die Benutzer wurden zunehmend frustrierter und w tender weil der Kopierer nicht das produzierte was sie wollten und sie sich selber nicht zu helfen wussten Dieses Video zeigte den Entwicklern zum ersten Mal auf dass die von ihnen nach allen Regeln der Kunst entwickelten Kopierger te aufgrund der zu komplizierten Benutzeroberfl che nicht bedienerfreundlich waren Unter Ber cksichtigung dieser Beobachtungen wurde eine neue Oberfl che entworfen Das Resultat Die durchschnittliche Zeit zur Behebung eines Papierstaus wurde von 28 Minuten auf 20 Sekunden reduziert 2 2 Grundlagen 2 1 Werkzeuge der Benutzerschnittstelle Eine Analogie griechisch analogos proportional entsprechend verh ltnism ig ist die hnlichkeit zwischen zwei Strukturen die aber nicht die gleiche Entstehungsgeschichte haben Wenn sich etwas analog zu etwas anderem verh lt kann man vom
295. ngehende Informatiker kurz erl utern Es wird erkl rt wie viel Zeit die einzelnen Phasen des Wasserfallmodells beanspruchen und welche Arbeit in einer gewissen Zeitspanne realistisch erscheint und korrekt ausf hrbar ist Allerdings beinhaltet dieses Mo dell auch einige M ngel wie etwa den fehlenden Ein bezug des Software Reuse und oder individueller Er fahrungen 4 1 Aufwandsabsch tzung f r die einzelnen Phasen des Wasserfallmodells Das Wasserfallmodell umfasst sechs Phasen die je weils mit der Fertigstellung eines Dokumentes abge schlossen sind 3 ber den Anteil an Entwicklungszeit die jede ein zelne Phase ben tigt gibt es jedoch unterschiedliche Meinungen So schl gt Ricketts beispielsweise eine Aufteilung wie in Abb 4 1 f r neue Projekte ber de ren Ablauf das Unternehmen noch keine Erfahrungen aus hnlichen Projekten hat vor 3 Abb 4 1 Projektaufwand Thaller hingegen sch tzt den Entwicklungsaufwand wie in Tab 4 2 beschrieben 4 Jedoch betonen beide dass es sich hierbei nur um Richtlinien handelt Tab 4 2 Phasen des Wasserfallmodells Phase Dokument Entwicklungs zeit in Anforderungs Anforderungsdefi 15 analyse nition Planung Gantt Chart bspw 2 Entwurf Design Anforderungsspezi 20 fikation Implementierung Entwurfsvorgaben 36 Kompilierung Test Implemen 25 tierungsvorgaben Post Mortem 2 Es f llt auf dass Thaller auch die Planung in die Entwicklung
296. ngsstrategie unsystematisch Die Szenario basierte Lesetechnik basiert auf vordefinierten Rollen innerhalb des Entwicklungs beziehungsweise des Inspektionsteams Es werden verschiedene Sichtweisen Fehlerklassen und Dokumententeile in den Mittelpunkt der Unter suchung gestellt Dabei werden den Inspektoren in konkreten Anleitungen den Szenarien sowohl die Vorgangsweise als auch die wichtigen zu beachtenden Kriterien vorgegeben Die Inspektoren versetzen sich also in die Lage einer Rolle und untersuchen das Dokument hinsichtlich der entsprechenden f r die jeweilige Rolle definierten Aspekte M gliche und in der Praxis h ufig verwendete Rollen sind beispielsweise die Designer Tester Anwenderrolle Biffl 2001 In der Regel gibt es f r die jeweiligen Rollen geeignete Leitf den in denen die wesentlichen Schritte definiert sind Aufgrund der rollenspezifischen Vorgangsweise m ssen diese Leitf den bei ge nderten Anwendungsdom nen nur geringf gig modifiziert werden Durch die verschiedenen Sichten der Rollen werden unterschiedliche Fehlerarten aufgefunden Bei der Anwendung von szenariobasierten Leetechniken ist zu beachten dass alle Fehlerkategorien durch die Rollen gefunden werden k nnen Bei dieser Methode muss darauf geachtet werden dass durch die Anwendung der Lesetechnik auch alle m glichen Fehler tats chlich gefunden werden k nnen Die Aufgabenpakete m ssen daher entsprechend gestaltet sein Die angewendete Lese
297. niedergeschrieben und es existiert viel leicht auch schon ein erster Entwurf Die Sch t zung basiert auf Function Points 3 The Post Architecture Model Die Stufe nach dem Architekturentwurf Die Systemarchitektur wurde bereits entworfen und demzufolge kann eine genauere Bewertung erfolgen Das Post Architecture Model verwendet zur Feinabstimmung der Sch tzung eine Vielzahl von Multiplikatoren die u a die F higkeiten der 52 159 Mitarbeiter sowie die Produkt und Projekteigen schaften ausdr cken SOMMO1 2 3 1 The Application Composition Model Die fr he Prototypenstufe wie das Application Composition Model auch genannt wird dient als Unterst tzung bei der Sch tzung von Prototypen und Projekten die eine Software hervorbringen sollen die aus vorhandenen Komponenten zusammengesetzt wird In dieser fr hen Phase ist es noch sehr schwer eine genaue Bewertung durchzuf hren Die Basis stellen hier Object Points dar Sie sind bei Programmierspra chen der 4 Generation anwendungsbezogene bzw applikative Sprachen und anderen vergleichbaren Sprachen eine Alternative zu Function Points da sie im fr hen Stadium noch leichter zu sch tzen sind Bei Object Points handelt es sich nicht um Objektklassen sondern um eine gewichtete Sch tzung der folgenden Faktoren Anzahl der angezeigten Bildschirmmasken Einfache Masken und Dialogfelder gelten als 1 Object Point komplexere als 2 und sehr komplexe als 3 A
298. nn Evolution re Entwicklung versucht durch st ndiges Weiterentwickeln und darauf folgendem Erproben ein Programm Schritt f r Schritt aufzubauen Jede Neuerung wird sogleich in der nat rlichen Umgebung erprobt und sofort auf weitere Entwicklungsm glichkeiten untersucht Eine alte und intuitive Herangehensweise an evolution re Entwicklung ist trial and error nach Fertigstellung eines Programms oder eines Teils davon wird dieses sofort gestestet und die Fehler behoben Bei inkrementeller Entwicklung eines Programms spricht man bei den Zwischenstationen von Prototypen Ein derartiges Vorgehen eignet sich besonders wenn nderungen der Anforderungen zu erwarten sind oder das endg ltige Ergebnis am Anfang noch nicht klar ist und sich erst im Laufe des Entwicklungsprozesses ein Ziel herauskristallisiert 11 Anwendung findet es berall wo Benutzer und Kunden eng in den Entwicklungsprozess eingebunden sind ein Beispiel hierf r w re Extreme Programming hier wird ein Wunsch des Kunden umgesetzt um ihm dann das Ergebnis zu pr sentieren und dann weitere W nsche in Angriff zu nehmen Reuse erm glicht es Programmierern bew hrte Teile oder Aspekte von Programmen auch in Zukunft wieder zu verwenden Das alte Paradigma der Software 82 159 Entwicklung bedeutete Software immer von Grund auf neu zu entwickeln Programmierer waren teilweise sogar der Meinung Programmcode m sse den gleichen urheberrechtlichen Regeln unterw
299. nn auch ohne viel Systemverst ndnis Hier sind jedoch 2 Arten der Vollst ndigkeit zu notieren die erste Art besch ftigt sich mit der Abdeckung des Problems in der Spezifikation sprich alle rele vanten Anforderungen m ssen hier abgefangen werden Die zweite Art bezieht sich auf den Standart der Anforderungen sprich alle Anfor derungen m ssen in dem zuvor definierten Standart spezifiziert worden sein um so die Korrektheit des Systems zu gew hrleisten 4 Au erdem wird das gleiche Wissen h ufig in den unterschiedlichen Darstellungen beschrie ben z B w rtlich und graphisch Wenn man sich entlang dieser Linie bewegt kommt es sehr oft zu kognitiven und psychologischen Proble men 12 e Dimension der Vereinbahrung Diese Achse betrifft die Vereinbahrungen die zu Beginn ge troffen wurden und die bei der gegenw rtigen Spezifikation zu erreichen sind Auf Grund des sen dass das Requirements Engineering hier als ein Prozess der Vermittlung und des Lernens angesehen wird sollte diese Vereinbarung ge troffen werden bevor begonnen wird das Sys tem zu entwickeln Folglich besch ftigt sich die se Linie haupts chlich mit Sozialaspekten der Anforderungsdefinition 12 Abschlie end w re hier zu vermerken dass bei der Gestaltung der Informationen w hrend des Systement wicklungsprozesses SEP drei grundlegende Aspekte zu beachten sind 12 e Die Verwendung von Trace Informationen ist stark von der jeweiligen Pers
300. nsanalyse und Mutationstesten zur Verf gung zu stellen 1 Wir wollen uns im Folgenden auf den dritten Grund konzentrieren die automatische Unterst tzung der Analyse und des Tests von Java Programmen Ein Tool m sste grunds tzlich folgende Aufgaben ausf hren k nnen 1 Den Sourcecode und die Mutanten erstellen 2 Aquivalente Mutanten finden und eliminieren 3 Die Testf lle mit dem Originalprogramm durchf hren 4 Wenn sie bestanden wurden diese auch mit den Mutanten durchf hren 3 analysieren Weiters muss festgehalten werden welche Mutanten erkannt werden konnten und welche nicht 2 Um den ersten Punkt die Erstellung der Mutanten zu erleichtern wurde der Metamutant entwickelt Ein Metamutant ist ein Programm dass alle Mutanten enth lt ber eine Umgebungsvariable wird bestimmt welcher Mutant ausgef hrt wird 3 Weiters kann durch Konzepte wie selective Mutation und weak Mutation die Anzahl der Mutanten verringert werden 1 142 159 Wie im dritten Abschnitt der Arbeit gezeigt wurden zur Erstellung der Mutanten Operatoren entwickelt die h ufige Fehler im Bereich der objektorientierten Programmierung im Speziellen in Java abdecken Auch diese Voraussetzung f r die Entwicklung eines Tools ist gegeben Eines der Hauptprobleme bei der Erstellung des Tools liegt im Erkennen und Aufl sen von quivalenten Mutanten Durch automatische Methoden k nnen bereits bis zu 60 der quivalent
301. ntwickler Die Menschen sind offen f r alles das ihr Leben erleichtern oder erweitern kann und dies erm glicht es gro en Geistern sich in ihrem Ideenreichtum auszutoben 45 159 In der im Mai 2004 erschienen Ausgabe der Autotouring Zeitschrift wird ein verhei ungsvoller Einblick in das Auto von Morgen gegeben So sollen die Elektronik und Software fast die gesamte Kontrolle ber das Fahrzeug bernehmen e Fahrspuren Erkennung Erkennt bei vorhandenen Begrenzungslinien die Position innerhalb der Fahrspur und warnt bei Gefahr von der Stra e abzukommen e Umfeldwahrnehmung Verkehrszeichen Stopp Tempolimits etc und Hindernisse werden auf die Scheibe projiziert Ma nahmen eingeleitet e mechatronische T rgriffe Das Aus f r die Schnalle Wenn man sich einer bestimmten Fl che n hert oder sie ber hrt ffnet die T r von selbst e Totwinkel berwachung Radar Sensoren an Spiegeln und R dern berwachen den toten Winkel in einer Distanz von 0 5 bis 40 Metern schlagen im Ernstfall Alarm e Fahrdynamik Regelung Heute nur in Grenz Situationen bald jedoch st ndige elektronische Antriebs Brems Lenk und Fahrwerks Regelung e Drive by Wire Mechanische Elemente wie Lenkgest nge und Gas Seil werden durch Datenkabel und Elektromotoren ersetzt e Aufmerksamkeitskontrolle Die Cockpit Kamera berwacht den Lidschlag die Software berechnet das Sekundenschlaf Risiko weist auf Ruhepausen hin
302. nun die Anzahl der verschiedenen genutzten Variablens tze Be nutzen alle Methoden die gleichen Variablen so existiert nur ein Variablensatz und LCOM hat den Wert eins Ein Man gel an Koh sion deutet darauf hin dass Klassen m glicher weise in zwei oder mehrere Subklassen aufgeteilt geh ren Geringe Koh sion erh ht weiters die Komplexit t womit auch die Wahrscheinlichkeit von Fehlern w hrend des Ent wicklungsprozesses steigt 4 ANDERE METRIKEN Aus der Menge der inzwischen ber 200 definierten Metriken f r objektorientierte Software werden folgend einige weitere Metriken angef hrt darunter Metriken von Sharble und Co hen sowie Lorenz und Kidd 4 1 Metriken von Sharble und Cohen Bei ihrer Untersuchung von Vorgehensweisen zur Entwick lung von objektorientierten Programmen benutzten Sharble und Cohen die Metriken von Chidamber und Kemerer und erweiterten diese um drei Metriken Weighted attributes per class Number of tramps Violations of the Law of Demeter siehe 7 4 1 1 Weighted attributes per class WAC Das Ergebnis dieser Metrik ist die Anzahl der Variablen einer Klasse gewichtet mit dem Umfang der Klasse Auch hier werden analog zur Metrik WMC nur die Variablen gemessen und nicht die Methoden Das Ergebnis von WAC ist ein Indiz dafiir wieviel Zeit und Aufwand erforderlich ist das Objekt weiterzuentwickeln und zu warten Je mehr Variablen in einer Klasse vorhanden sind desto gr er ist die Auswirku
303. nverteilung anders vorgenommen wird Bei einem Walkthrough stellt der Autor den Review Teilnehmern ein Dokument vor und arbeitet dieses Schritt f r Schritt mit ihnen durch Im Gegensatz dazu hat der Autor bei einer Inspektion nur die Aufgabe entdeckte Fehler nachtr glich zu korrigieren und Fragen zu beantworten Au erdem unterscheiden sich diese zwei Arten auch noch durch die Art und Weise wie das Dokument durchgearbeitet wird Bei einem Walkthrough wird das Dokument genau so wie es vorliegt von oben nach unten durchgelesen wogegen es beim Einsatz einer Inspektion die verschiedensten Lesetechniken gibt auf die ich noch sp ter zu sprechen kommen werde 3 Formale Inspektion Eine Inspektion wird als eine statische Analysemethode um Qualit tseigenschaften von Softwaredokumenten zu berpr fen definiert Sie ist eine ganz spezielle Art und Weise wie ein Review durchgef hrt wird welche Personen in diese berpr fung miteinbezogen werden und welche Rollen diese bernehmen Sie dient dazu die w hrend des Entwicklungsprozesses generierten Dokumente zu analysieren Zu diesen Dokumenten geh ren unter anderem die Produktanforderungen Design Diagramme und der Quellcode Ebenso wie ein Review wird die Inspektion verwendet um Fehler in fr hen Stadien der Softwareentwicklung zu finden und ein Softwareprodukt im Hinblick auf die 21 159 Einhaltung von Standards und Vorgabedokumente wie etwa das Anforderungsdokument zu b
304. nzahl der erzeugten Berichte Einfache Berichte z hlen f r 2 komplexere f r 5 und schwer erzeugbare Berichte f r 8 Object Points Anzahl der Module in Programmiersprachen der 3 Generation h here Programmiersprachen Jedes Modul das in einer h heren Programmier sprache erzeugt werden muss z hlt f r 10 Object Points Die errechneten Object Points werden in weiterer Folge durch einen Standardwert f r die Produktivit t dividiert Dieser Wert ist abh ngig von der Erfahrung und Fertigkeit des Programmierers sowie von den F higkeiten der verwendeten CASE Werkzeuge und l sst sich aus Tabelle 1 ersehen BOEH00 Tabelle 1 Produktivit t in Object Points pro Monat Die Formel zur Berechnung des Aufwandes in Per sonenmonaten PM sieht wie folgt aus SOMMO1 PM OP 1 reuse 100 PROD bzw PM NOP PROD NOP OP 1 reuse 100 Abbildung 3 Formel Application Composition Model 2 3 2 The Early Design Model Dieses Modell wird im Deutschen Die fr he Entwicklungsstufe genannt Die Sch tzungen die in dieser Stufe erfolgen basieren auf der Standardformel algorithmischer Modelle siehe Abbildung 4 Das Modell wird wie sein Name bereits aussagt in der fr hen Phase der Entwicklung wo noch wenige Informationen ber Umfang des Projektes Zielplattform Eigenschaften der Personen die bei die sem Projekt mitarbeiten und keine Einzelheiten des Entwicklungsprozesses vorliegen verwendet Es eig ne
305. o erkennt Handschrift des Fahrers zu finden unter http www alldengineers com Datum April Mai 2004 25 http www ttatwest net porttal presse wiwo2k20919 html Datum April Mai 2004 26 Auto Touring Clubmagazin des Oamtc Ausgabe Mai 5 2004 zu finden u a unter http www oeamtc at Datum April Mai 2004 27 MISRA Guidelines zu finden unter www misra org uk Datum Mai 2004 28 http de encarta msn com Datum April Mai 2004 29 M Kurzmann Bosch Engineering GmbH Testen leicht gemacht zu finden unter http en etasgroup com downloads rt rt_2003_02_36_ en pdf Datum Mai 2004 48 159 Aufwandsschatzung am Beispiel COCOMO II Daniela ESBERGER 0160072 daniela esberger edu uni klu ac at Abstract Nur allzu oft wird aus vermeintlich logischen Gr n den wie beispielsweise Zeitersparnis auf eine sorgf l tige Aufwandssch tzung verzichtet Dabei bildet sie einen Grundpfeiler des Projektes und sollte daher auch ihrem Stellenwert entsprechend behandelt wer den Im Speziellen bei Projekten f r externe Auftrag geber bildet die Aufwandssch tzung die Basis jeder Angebotserstellung aber auch bei internen Projekten sollte sie nicht vernachl ssigt werden Oft wird eine Sch tzung nur zu Beginn durchgef hrt und auf eine regelm ige Kontrolle und Beobachtung des Verlau fes um gegebenenfalls vorbeugend einzugreifen ver gessen Im Folgenden soll das Thema Aufwandssch t zung n
306. objekt orientierte Metriken durchgef hrt In dieser Studie wurden f nf Metriken aus 5 und zwei Metriken aus 15 verwendet Die Autoren kamen zu dem Ergebnis dass die Gr e einen starken Einfluss auf WMC DIT RFC LCOM und NMA hat Nachdem die Verzerreffekte der Gr e korrigiert wur den wiesen die Metriken nur mehr einen sehr schwachen WMC RFC NMA oder gar keinen Zusammenhang DIT LCOM NPAVG mit der Variable Fehleranf lligkeit auf Aufgrund dieser Ergebnisse scheint es ratsam zu sein vorher gehende Validierungsstudien nochmals kritisch zu hinter fragen und den Verzerreffekt der Gr e entsprechend zu ber cksichtigen 7 CONCLUSIO Auch wenn auf dem Gebiet der objektorientierten Software metriken schon ber zehn Jahre Forschung betrieben wird und inzwischen ber 200 Metriken vorgeschlagen wurden ist es im Vergleich zum Gebiet der traditionellen Metriken dessen Wurzeln in die sechziger und siebziger Jahre zur ck gehen noch relativ jung Somit ist es nicht verwunder lich dass es noch einige Probleme und Fragestellungen im Besonderen die Grenzwertproblematik und der Einflu der Klassengr e auf die Validierung von Metriken gibt de nen noch vermehrt Aufmerksamkeit geschenkt werden muss Und auch wenn den Anwendern dieser objektorientierten Metriken eine gro e Menge von Metriken zur Verf gung steht stellt die Auswahl der f r sie passenden Metriken oft ein gro es Problem dar Es w re daher von Vorteil
307. ods per Class Berechnet man McCabe s Cyclomatic Complexity auf Methoden so kann man daraus die sogenannte Weighted Methods per Class WMC von Chidamber und Kemerer bestimmen WMC ist nichts anderes als die Summe aller CC Werte der Methoden einer Klasse WMC wirkt sich auf den Entwicklungsaufwand der Klasse aus Eine Klasse mit h herer Methodenanzahl wirkt sich in der Regel auch st rker auf die m glichen Subklassen aus weil diese auch entsprechend mehr Methoden erben Eine Methodenzahl ist auch ein Indiz daf r da es sich um eine sehr anwendungsspezifische Klasse handeln k nnte was die Wiederverwertbarkeit negativ beeinflu en w rde Wie hoch der WMC Wert einer Klasse im Optimalfall sein soll ist nicht von vornherein klar Software Unternehmen k nnen WMC verwenden indem sie Grenzwerte auf Basis der eigenen Erfahrung oder ihnen bekannten 6Es m ssen alle m glichen Paar Kombinationen gebildet werden TNDC number of direct connections between public methods 3 SNIC number of direct or indirect connections between public methods 3 Studien festsetzen Aber auch ohne empirische Vergleichswerte l t sich WMC sinnvoll nutzen um die komplexesten Klassen in einer Software zu identifizieren 3 2 2 Average Method Complexity Die Average Method Complexity von Morris 9 ist wie der Name bereits vermuten l t das arithmetische Mittel der Cyclomatic Complexity aller Methoden Eine hohe Komplexit t der Methoden wi
308. oftwareentwicklung und vergleicht sie mit dem traditionellen Ansatz Weiters wird aufgezeigt wie Oualit tssicherung betrieben wird und in wie weit diese sich beim agilen Ansatz ndert 1 Einleitung Agile Softwareentwicklung versucht sich der Her ausforderung zu stellen schnell an ge nderte Kun denw nsche zu reagieren und diese schnellstm glich umzusetzen Diese Art von Softwareentwicklung hat ihren Ursprung durch das Aufkommen von eXtreme Programming 6 7 und wird insbesondere durch die steigende Anzahl von Internetprojekten gest tzt In ternetprojekte beziehungsweise Softwareentwicklung f r das Internet sind Paradebeispiele f r das Problem der h ufigen nderungen von Kundenanforderungen w hrend des Verlaufs eines Projektes Gerade hier versuchen die Methoden der agilen Softwareentwick lung sich zu etablieren und eine L sung zu bieten Diese L sung steht im Gegensatz zu den herk mmli chen Methoden der Softwareentwicklung die dieses Problem durch ihre strenge Prozessorientiert zu l sen versuchen Agile Prozesse versuchen durch einen an gepassten und beschleunigten Entwicklungsprozesses und durch die Einbindung des Kunden dieses Problem zu meistern Dabei stellt sich aber die Frage welchen Platz die Qualit tssicherung hierbei einnimmt und ob dadurch die Qualit tssicherung beeinflusst wird Diese Arbeit untersucht diese Frage und untersucht agile Softwareentwicklung hinsichtlich der Qualit ts sicherung und ihren M
309. on GQM Um in einer Organisation ein Softwaremesspro gramm zu etablieren bedarf es nat rlich nicht nur des praktischen Know Hows sondern besonders f r das Organisationsmanagement ist auch der wirtschaftliche Aspekt eines solchen Programms von gro er Bedeu tung In diesem Kapitel soll deshalb eine grobe Kos ten Nutzenabsch tzung f r die Durchf hrung eines GQM Programms geliefert werden 3 1 Kosten von GQM Das hier pr sentierte Kostenmodell ist dargestellt in 6 und basiert auf der Anwendung von sechs ver schiedenen GQM Programmen Bei der Betrachtung der Kosten muss zwischen der regelm igen Anwendung und der erstmaligen Einf h rung eines GQM Programms unterschieden werden Diese Unterscheidung ist notwendig da bei der Erst einf hrung eines Messprogramms ein verh ltnism ig h herer Aufwand besteht als bei der wiederholten An wendung In jeder der im vorherigen Kapitel beschriebenen Phasen entstehen verschiedene Kosten die hier kurz aufgeschl sselt werden sollen In der Planungsphase entstehen Kosten durch die Vorbereitung der Infra struktur die Festlegung von Verbesserungszielen die Auswahl eines Projektes die Erstellung eines Projekt plans und durch die Ausbildung und Vorbereitung der Mitarbeiter welche dann das GQM Team bilden Die ses ist f r die Durchf hrung bzw f r die weitere Pla nung des GQM Programms zust ndig In der Definiti onsphase m ssen die GQM Goals Questions und Me
310. on kleiner gleich vier 4 2 5 Interne Merkmale von Methoden Diese Gruppe von Metriken besch ftigt sich mit den inter nen Charakteristiken von Methoden Mittels der Metrik Method complexity soll die Komplexit t von Methoden be stimmt werden Hierbei werden den Konstrukten der Pro grammiersprache API Aufrufe Zuweisungen bin re Aus dr cke arithmetische Operatoren Nachrichten Parameter geschachtelte Ausdr cke tempor re Variablen un re Aus dr cke usw Werte zugewiesen die dann summiert werden Als Grenzwert empfehlen Lorenz und Kidd den Wert 65 4 2 6 Interne Merkmale von Klassen Diese Metriken beziehen sich auf das Design der internen Charakteristiken von Klassen etwa wie Instanzvariablen ver wendet werden oder welche externen Referenzen sie anlegen Die Metrik Global Usage zahlt die Anzahl von globalen Vari ablen wie Systemvariablen oder Klassenvariablen Da ein vermehrter Einsatz von globalen Variablen auf schlechtes objekt orientiertes Design hindeutet sollte deren Einsatz reduziert werden Als Grenzwert wird eine Systemvariable angegeben jeder weitere Einsatz von globalen Variablen mu gut begr ndet werden 4 2 7 Externe Merkmale von Klassen Metriken dieser Art untersuchen wie sich eine Klasse auf andere Klassen Subsysteme Benutzer usw bezieht Die Metrik Number of times a class is reused bezieht sich auf einen der gro en Vorteile der Objektorientierung die zus tz liche Unterst tzung von Reuse Au
311. onengruppe und der Phase des Softwareentwicklungsprozesses abh ngt Das hei t dass Trace Informationen sp ter in einem anderen Kontext verwendet werden als sie vorher aufgezeichnet wurden Die Strukturierung und Verwaltung der erfass ten Daten muss also spezifische Sichten und ein selektives Retrieval gem dem aktuellen Be darf bei der Verwendung unterst tzen e Zweitens bietet aufgrund der gro en Informati onsmenge die w hrend der Prozessdurchf h rung anf llt nur eine Inhaltsorientierte in einen breiteren Prozesskontext eingebettete Erfassung von Trace Informationen eine Basis zur geeig neten Wiederverwendung e Drittens sind die Personen die in die Trace Erfassung involviert sind nicht identisch mit den Verwendern der aufgezeichneten Trace Informationen Daher wird eine standardisierte Traceability Struktur ben tigt die garantiert dass Trace Informationen stets auf die gleiche Art erfasst werden um dadurch eine einfachere Verwendung durch Dritte zu erm glichen 8 3 Arten des Requirements Tracing Vorweg w re zu diesem Thema zu vermerken dass es alles in allem 4 Arten des Requirements Tracings gibt 3 Forward from Requirements Hier geht es um die Zuweisung der Verantwortlichkeit f r die Ausf hrung der Anforderungen an die Systembestandteile Es muss gew hrleistet werden dass die Verantwortlichkeit hergestellt wird und die Auswirkung der Anforde rungs nderungen ausgewertet werden kann Ba
312. orderungs Tools reifte RT um so Projekt Auswirkungs Analyse und n derungs sowie Defektmanagement zu st tzen und weiters eine Verbesserung der Fertigungsprozesse und Teamkommunikationen zu erzielen Heute bietet das Anwenden von Traceability ein hohes Niveau der Projektsteuerung und der sicheren Qualit t an die durch alle m glichen anderen Mittel schwierig zu erzielen ist 15 5 1 Kosten und Nutzen von RT Abh ngig davon wie Unternehmen die Traceabili ty Informationen einsetzen kommt es zu einem dem 74 159 entsprechenden Nutzen An einem Minimum k nnen Projekt Entwicklungs und Pr fungsgruppenleiter pr fen ob alle Kundenanforderungen eingef hrt und gepr ft worden sind und ob Qualit t zuverl ssige Systemf higkeiten und eigenschaften sichergestellt sind Das Anwenden von RT gibt Organisationen sogar erheblichere Vorteile erh hte Qualit t verringerte Kosten und Verbesserung des Gefahren und Projekt managements f r Projekte gegenw rtige und zuk nf tige 15 Traceability lasst uns alle Produktanforderungen sehr fr h im Life Cycle der Entwicklung zuteilen und somit erheblich Geld sparen l sst Die Kosten die sonst beim Warten entstehen bis die Integration und Sys tem Test Phase abgeschlossen ist um Defekte zu be heben ist ein fixer Bestandteil und ist 30 mal starker als bei der vorgesehenen Ausgangsphase 2 6 Conclusio Beginnen m chte ich das Fazit mit 2 Zitaten die die Re
313. orfen sein wie literarische Werke 12 Sp testens seit dem Aufkommen der objektorientierten Programmierung hat sich dieses Paradigma ge ndert und Programmcode wird nun als Werkzeug betrachtet und wenn sinnvoll wieder verwendet Neben der technischen Ebene auf der Reuse Zeitersparnis f r den Programmierer bedeutet kann auf der Anwendungsebene eine Wiederverwendung von Komponenten die Vertrautheit mit dem neuen Gesamtprodukt erh hen Abgewogen werden m ssen hier der Verlust von Verbesserungsm glichkeiten und die leichtere Erlernbarkeit des Programms Um das Verhalten eines Programms mit den Erwartungen der Benutzer zu harmonisieren kann man zus tzlich zum Gedankenmodell das der Benutzer vom Programm hat ein Verhaltensmodell eines Systems erstellen Ein einzelnes Verhalten ist optimalerweise eine einzelne Funktion die eine f r den Benutzer klar umrissene Aufgabe hat und deren Ergebnis eindeutig verifizierbar ist Hilfreich um dieses Verhalten dem Benutzer deutlich zu machen ist der Einsatz von Ger uschen die sofort R ckmeldung ber den Erfolg geben Die verschiedenen Verhaltensweisen eines Systems setzen sich zusammen aus den Erwartungen der Benutzer Grenzen der Machbarkeit und Verhaltensmustern an die sich das System halten soll Das Verhaltensmodell eines Systems stellt klar was das Programm tut was es tun kann und was es nicht tun kann oder soll ber Aktionsdiagramme wird das Verhaltensmodell spezifiziert Im Laufe des P
314. ottom Up Methode ist das Gegenst ck zu Top Down und kann ebenso in Kombi nation zu den anderen Methoden angewandt werden Es wird jede einzelne Komponente gesch tzt und zu einem Gesamtaufwand addiert Die Vor und Nachteile sind demzufolge gegengleich zu Top Down 2 COCOMO II COCOMO z hlt zu den algorithmischen Modellen zur Kosten und Aufwandssch tzung von Software COCOMO wurde Ende der siebziger Jahre erschaffen und 1981 von Barry Boehm ver ffentlicht Barry W Boehm studierte Mathematik in Harvard und ist heute Professor an der University of Southern California Den GroBteil seiner Arbeiten entwickelte er wahrend seiner Beschaftigung bei TRW wo er von 1973 bis 1989 Hauptwissenschaftler der Verteidi gungssystemgruppe war Neben COCOMO entwickel te er auch das spiralf rmige Modell des Softwarepro zesses die Theorie W win win das TRW Software produktivit tssystem und die Quantensprungumge bung Sein heutiger Forschungsbereich umfasst Soft wareprozessmodellierung Software Requirements Engineering Softwarearchitekturen Softwarema sys teme Kostenmodelle Softwaretechnikumgebungen und wissensbasierte Softwaretechnik TUWI04 Das COnstructive COst MOdel COCOMO ba siert auf empirischen Werten die aus Datensammlun gen aus verschiedenen Projekten und Analysen ge wonnen wurden SOMMO01 COCOMO II ist gut f r die Anwendung in Unter nehmen geeignet und geh rt zu den wenigen Sch tz verfahren die alle Einfl s
315. ozess der Dokumentation identifiziert da einerseits die Verbin dungen zwischen Benutzeranforderungen an das Sys tem begutachtet werden und andererseits das Produkt das entwickelt wird um jene Anforderungen einzuf h ren und zu berpr fen Zus tzlich wird in dieser Arbeit noch ber die Oualit tsaspekte durch den Einsatz des Requirements Tracing und den damit verbunden Kos ten referiert 1 Introduction Bei RT geht es im engeren Sinn um die F higkeit das Leben einer Anforderung w hrend des Life Cyc les zu beschreiben und zu verfolgen In diesem Zu sammenhang w re zu notieren dass Traceability als eine unentbehrliche Verbindung oder definierbares Verh ltnis zwischen Wesen anzusehen ist Die An forderung ist eine Softwaref higkeit die durch ein System oder einen Bestandteil getroffen sein muss um einen Vertrag eine Spezifikation einen Standard oder ein anderes formales Dokument zu erf llen 1 In dieser Arbeit wird das grundlegende Problem des Requirements Tracing und des Requirements Traceabi lity analysiert Im Kapitel 2 wird zu Beginn genau beschrieben warum Requirements Tracing betrieben werden sollte und vorallem wie Im anschlie enden Kapitel 3 wird auf die 2 Haupt arten des RT eingegangen einerseits das Pre Traceability und andererseits das Post Traceability Hier werden von mir die m glichen Probleme identifi ziert und die m glichen L sungsans tze und Support M glichkeiten kurz auf
316. ozessanalyse und die Prozessverbesserung herangezogen werden kann 5 4 5 Stufe 5 Optimizing Auf Stufe 5 ist der zuverl ssige Ablauf des Softwareprozesses Routine und erm glicht es den Beteiligten sich auf eine kontinuierliche Prozessverbesserung zu konzentrieren Alle Mitarbeiter wissen welche Aufgaben wann zu erledigen sind Sie konzentrieren sich nun darauf den Softwareprozess so zu ver ndern um Wettbewerbsvorteile durch h here Qualit t und Produktivit t zu erzielen Sobald die Produktionsmechanismen effektiv und effizient sind sowie gelenkt werden k nnen sich die Mitarbeiter auf deren Verbesserung konzentrieren 2 Im optimierten Prozess wird gro es Augenmerk darauf gelegt Fehler innerhalb des Prozesses m glichst fr h zu erkennen und die Kosten f r deren Beseitigung m glichst gering zu halten Dies kann u a durch vermehrte Inspektionen erreicht werden Zus tzlich wird die Qualit t des Prozesses dadurch verbessert dass umfangreiche Prozessdaten fortlaufend erfasst und ausgewertet werden 5 SPBs auf dieser Stufe sind Die Fehlervermeidung zielt darauf ab allgemeine Ursachen f r Prozessabweichungen zu lenken Dass dieser SPB auf Stufe 5 platziert ist bedeutet jedoch nicht dass Organisationen auf niederen Reifegraden keine Fehlervermeidung praktizieren Eine stabile Form der Fehlervermeidung basiert auf folgenden Aktionen Analyse der Vergangenheit Vorhersage des Entwicklungstrends Erkennen der grundlegen
317. p okr Kalendermonata Abb 4 3 Gantt Chart 5 Individuelles Zeitmanagement 5 1 Methoden der effizienten Zeitplanung Es ist sehr wahrscheinlich dass man immer wieder ahnlichen Tatigkeiten sowohl im Berufs als auch im Privatleben Woche f r Woche nachgeht Dennoch sollte man versuchen m glichst genau aufzuzeichnen womit man seine Zeit verbringt denn oft tr gt das in tuitive Zeitgef hl Aus diesen Aufzeichnungen kann man in weiterer Folge einen Zeitplan erstellen und versuchen seine Zeit noch besser einzuteilen Hierbei ist es vor allem wich tig dass man den Plan konsequent verfolgt und falls er sich als zu ungenau herausstellt anpasst Im Folgenden werden einige von Humphrey 1 ent wickelte Methoden vorgestellt die dabei helfen k n nen die Zeit sowohl f r Softwareentwickler als auch Sch ler realistisch zu planen 5 1 1 Engineering Notebook Um festzustellen wie man seine Zeit nutzt ist es hilfreich die momentanen unz hligen Aktivit ten zu kategorisieren damit der Zeitplan bersichtlich auf einige wenige aber wichti ge Hauptkategorien die bei Bedarf noch verfeinert werden k nnen beschr nkt bleibt Das Engineering Notebook dient vor allem dazu eine chronologische Ordnung in die Aufzeichnungen zu bringen Als sinnvoll entpuppt sich daher ein von ihm vorgeschlagenes Inhaltsverzeichnis da es die bersichtlichkeit im Notebook erh ht Ein Engineering Notebook kann aber auch Notizen zu Gespr
318. pezielle Art des Re pository Designs das Regressionstesten erleichtern soll auf ein Maturity Model f r den komponentenba sierten Test Prozess sowie auf einen Vorschlag zur Automatisierung des Testens Weiters werden Modelle vorgestellt die zur Durchf hrung der Tests nicht un bedingt auf der Kenntnis des Sourcecodes beruhen 1 Einleitung Komponentenbasierte Softwareentwicklung erleich tert die Software Wiederverwendung und f rdert somit Produktivit t und Qualit t Nicht nur die Qualit t der Software Komponenten sondern besonders auch die Effektivit t der Testprozesse tragen zur Qualit t des Gesamtsystems bei Gerade auf das Testen im Zusam menhang mit komponentenbasierter Software wurde in letzter Zeit in der Literatur eingegangen 1 2 Einige Ans tze werden in dieser Arbeit behandelt In Kapitel 2 wird ein kurzer berblick ber die komponentenbasierte Softwareentwicklung gegeben In Kapitel 3 wird eine Abgrenzung bestimmter Begrif fe vorgenommen die die Bereiche Komponentenba sierte Softwareentwicklung sowie Testen umfassen Kapitel 4 ist der Hauptteil der Arbeit und stellt die An s tze des Testens komponentenbasierter Software vor Einerseits geht es dabei um Modelle bei der die Kom ponenten als Software Module behandelt werden Ka pitel 4 1 bis 4 3 Andererseits wird die Komponente als bin rer Software Baustein gesehen In Kapitel 4 4 werden L sungsans tze f r das Problem des Testens bei fehl
319. prozess Begutachtung d extended Abstracts und Begutachtung d full papers 20 Full paper submitted version final version 30 Vortrag 20 152 159 laufende Mitarbeit Diskussion 10 wobei allerdings zu ber cksichtigen ist dass eine positive Seminarteilnahme nur dann gegeben ist wenn in allen genannten Beurteilungsdimensionen die erforderlichen Beitr ge fristgerecht erbracht wurden Allf llige offene Punkte k nnen in der Vorbesprechung gekl rt werden Anmerkung Der Zeitplan wurde nach den Osterferien f r den Rest des Monats April und f r Mai wie folgt festgelegt Zu diesem Zeitpunkt war zwar die Zahl der Normalseminaristen bereits stabil der Dropout an Bakkalaureatsstudierenden jedoch noch nicht manifest Daher wurden die Vortragsbl cke Juni vorerst noch nicht genauer definiert 20 21 April 04 Kurzpr sentationen Diplomstudierende 4 min April 04 Kurzpr sentationen Bakkalaureatsstudierende 5 min 4 Mai 04 offen wird am 27 Apr besprochen 10 11 14 1 17 18 Mai 04 8 30 Uhr Reviews f r Bakkalaureatsarbeiten sind f llig von allen 24 25 Mai 04 8 30 Uhr Langfassungen der Diplomstudierenden sind eingereicht Fallfrist Mai 04 Begutachtungsaspekte Vortragsprogramm Mai 04 13 00 UhrReviews f r 2h Arbeiten sind f llig von allen Fallfrist Mai 04 8 30 Uhr Langfassungen der Bakkalaureatsarbeiten sind eingereicht Fallfrist Mai
320. prozessbereich je einen F higkeitsgrad auf einer Skala von 0 bis 5 gibt F higkeitsgrade beziehen sich somit auf einen Schl sselprozessbereich Reifegrade hingegen beziehen sich auf die Gesamtheit der Schl sselprozessbereiche einer Stufe 5 CMM in der Praxis Das SEI publizierte 1996 einen Erfahrungsbericht von Unternehmen die CMM in einem Zeitraum von ein bis drei Jahren zur Prozessverbesserung eingesetzt haben Von den 138 befragen Organisationen befanden sich nach Selbsteinsch tzung 87 auf Level 1 36 auf Level 2 und 15 auf Level 3 oder h her Die Befragung hatte das Ziel die CMM Reifegrade hinsichtlich folgender Kriterien zu untersuchen Einhalten von Termin und Budgetpl nen Kundenzufriedenheit Produktqualit t Arbeitsmoral und Arbeitsproduktivit t Bei folgenden vier Kriterien konnte ein statistisch relevanter Zusammenhang zwischen h herem Reifegrad und Leistungsf higkeit in einem bestimmten Bereich festgestellt werden Einhalten von Terminpl nen Produktqualit t Arbeitsmoral Arbeitsproduktivit t Die Kundenzufriedenheit bei Unternehmen auf Level 2 war tendenziell niedriger als bei Organisationen der Stufe 1 jedoch nahm die Zufriedenheit bei Level 3 wieder sehr stark zu Weiters wurden die Unternehmen befragt inwieweit sich ihre Softwareprozesse durch die Einf hrung von CMM verbessert haben Mehr als die H lfte der Befragten gab an dass sich der Prozess gut bis sehr stark verbessert habe Immerhin 30 waren der
321. r Wikis im Internet die in allen m glichen Bereichen eingesetzt werden gro teils f r Enzyklop dien Informationen von http www heise de 6 4 2 Speziell Die nun von mir zitierte Wiki Seite besch ftigt sich mit dem Akzeptanztest Genauer gesagt geht es darum dass sich Entwickler dar ber Gedanken machen wie sie es schaffen mit ihren Kunden fehlerfrei zu kommunizieren und die Kunden dazu zu bringen gute Akzeptanztests zu schreiben Auch die Frage ob das f r Nicht Programmierer ber haupt m glich ist wird hier aufgeworfen aber noch nicht ganz beantwortet Einige auf dieser Seite aufgeworfene Ideen und Vorgehensweisen m chte ich kurz aufz hlen Ein franz sischer Codierer der zwei B cher und einige Artikel ber Extreme Programming schrieb machte die Akzeptanztests selbst und zwar indem er sich mit den Kunden zusammensetzte und ihnen folgende Frage stellte Wenn Sie es w ren der jetzt den manuellen Akzeptanztest machen m sste was w rden Sie verifizieren Danach schrieb er den Test code so dass nach bestem Wissen und Gewissen die vom Kunden aufgez hlten Punkte behandelt wurden Die meisten Entwickler im Forum beschr nken den Abnahmetest auf einen Test des GU Interfaces in der Form Der Weiter Button soll genau an der Stelle 100 100 sein der Zuriick Button auf 150 100 oder Das Backup Item soll einen Dialog beginnen der einen Start Backup Button hat um das Backup zu beginnen Allerdings sind sol
322. r ben tigen um ein Softwareprodukt herzustellen Um den Fortschritt und die generelle Ausf hrungszeit des Softwareprozesses vorbestimmen zu k nnen ist es notwendig dass die Teilbereiche des Softwareprozesses statistisch messbar sind Das bedeutet dass jeder Teilbereich bei jedem Durchlauf des Softwareprozesses innerhalb einer vorgegebenen statistischen Grenze dieselbe Ausf hrungszeit hat und dieselben Ergebnisse liefert Erst unter Voraussetzung dieser statistischen Messbarkeit der Prozesse ist es m glich eine kontinuierliche Verbesserung des Softwareprozesses anzustreben 5 Das Capability Maturity Model definiert f nf Stufen der Reife einer Organisation bez glich seiner F higkeiten Software Entwicklungsprojekte durchzuf hren Das Modell soll helfen den Reifegrad von Softwareentwicklungsprozessen zu ermitteln um gezielte Prozessverbesserungen durchf hren zu k nnen Mit steigendem Reifegrad maturity level wird die Erwartung verbunden dass die Vorhersagbarkeit von Terminen Kosten und Qualit tszielen zunimmt F r jede der f nf Stufen definiert das CMM wie sich ein Prozess auf dieser Stufe darstellt Die einzelnen Stufen bauen aufeinander auf Eine Stufe setzt voraus dass die Anforderungen an die Prozesse die die anderen Stufen erfordern erf llt sind 1 Jeder Reifegrad setzt sich jeweils aus einer Sammlung von Praktiken zusammen In Organisationen die einen bestimmten Reifegrad erreicht haben sind diese
323. r von Dienstleistungen Probleme bei der Umsetzung der Normen Der Grund daf r lag vermutlich daran dass das zust ndige technische Komitee gr tenteils aus Experten des Produktionsbereiches bestand und somit Anforderungen von Software und Dienstleistungsun ternehmen unber cksichtigt blieben Aufgrund dieser Probleme wurden Leitf den ent wickelt die bei der Anwendung der Normen behilflich sein sollten Zum Beispiel ist ISO 9000 3 der Leitfa den f r die Softwareentwicklung Da in den letzten Jahren die Anzahl der Leitf den stieg und die Anfor derungen an die Normfamilie sich nderten beschloss das TC 176 eine Weiterentwicklung der Normenserie Der Entwurf der Version 2000 entstand 1990 und nachdem er von den Mitgliedsl ndern der ISO akzep tiert wurde wurde die DIN EN ISO 9000 2000 Normfamilie 1994 ver ffentlicht Diese Neufassung wurde im Dezember 2000 in Kraft gesetzt und seit An fang 2004 ist nur noch eine Zertifizierung nach DIN EN ISO 9000 2000 m glich Die Zertifizierung wird von einer unabh ngigen Zertifizierungsstelle vollzogen Diese erfolgt durch ein Audit und ist drei Jahre unter der Vorraussetzung dass j hrlich ein berwachungs Audit durchgef hrt wird g ltig Nach drei Jahren ist ein Wiederholungs Audit erforderlich Aus Gr nden der einfacheren Lesbarkeit wird DIN EN ISO bzw NORM EN ISO in dieser Ar beit mit ISO abgek rzt und die Versionsangabe erfolgt nachgestellt getrennt durc
324. r Standards sowie ausreichende Codedokumentation anhand von Komm entaren Teamarbeit soll ein breites Verst ndnis der einzelnen Teammitglieder gegen ber dem Produkt schaffen und so zu erh hter Qualit t und Prozessbe schleunigung f hren Der Vorteil der Teamarbeit kann sich aber durch die erh hte Kommunikation besonders bei gr eren Projekten leicht zu einem Nachteil ver kehren Der wesentlichste Vorteil hinsichtlich der Qualit tssicherung ist aber die st ndige Durchf hrung von Tests Die starke Einbindung des Kunden in den Verlauf der Softwareentwicklung soll die Erf llung der Anforderungen gew hrleisten Hierbei ist aber zu beachten dass Kunde nicht gleich Auftraggeber sein muss Der Kunde ist im Falle der Softwareentwicklung neben dem Auftraggeber der den Bedarf der Software erkennt und das Projekt initialisiert der Endanwender Eine genaue Identifikation und Einbindung entsprech ender Keyuser ist ma geblich f r den Erfolg von XP Projekten beziehungsweise bei agilen Projekten Besonders weil XP davon ausgeht dass der Kunde wei was er will und eine genaue Vorstellung der Software hat Eine Anforderungsanalysephase existiert in keiner herk mmlichen Form und anhand der Story cards muss der Kunde nach und nach sich ein Bild der Software zurechtlegen XP vermeidet jede zeitinten sive T tigkeit hier besonders die Dokumentation Dies kann insbesondere Probleme hinsichtlich der Auftrag vergabe bereiten Die Dokumentation b
325. r die Freiheit seine Vorstellungen umzusetzen und sp ter die Notwendigkeit eventuelle K ufer daf r zu begeistern Voreingenommen ist ein Entwickler aber nicht nur in der Anforderungsanalyse sondern auch in der Testphase denn durch sein umfassendes Wissen ber das Produkt ist er nicht mehr f hig dessen intuitive Verst ndlichkeit zu beurteilen Folglich ist es notwendig unbefangene Tester mit der Aufgabe zu betrauen aber f r die Entwickler bedeutet dies dass es f r sie n tzlich ist die Benutzer ihr Umfeld und grundlegende Elemente der kognitiven Psychologie zu kennen um ihre Reaktion auf die Benutzerschnittstelle besser einsch tzen zu k nnen Am sichersten f r den Entwickler ist hier die Annahme dass jeder einzelne Benutzer sich von allen anderen unterscheidet 7 3 Beispiele Ein Beispiel f r ein Programm mit einer sehr komplizierten und schwer zu erlernenden Benutzeroberfl che ist SAP Es handelt sich hierbei um ein sehr umfangreiches und m chtiges Verwaltungsprogramm das ber unz hlige 80 159 Bildschirme und Masken verf gt Konsistenz zwischen den einzelnen Masken ist gegeben die M glichkeiten einzelne Masken an die W nsche der Benutzer anzupassen besteht nicht SAP ist ein sehr starres Programm und Fehleingaben lassen sich nicht mehr so leicht korrigieren Um den Zugang zu den einzelnen Masken zu erleichtern k nnen diese mit vierstelligen Codes erreicht werden All dies b rdet dem Benutzer ein
326. r oben genannten Bewertung k nnen die Faktoren auch durch eine Kombination der im Post Architecture Model verwendeten Multiplikatoren be rechnet werden BOEH00 Wird ein bedeutender Teil des Codes automatisch erstellt so sollte dies auch ber cksichtigt werden Hier empfiehlt sich ein Formel mit der zus tzlichen Variab le PM PM A Gr e M PM siehe auch Abbil dung 4 Obwohl auch hier meist manuelle Eingaben erforderlich sind ist der Produktivit tsgrad signifikant h her als bei manuell erstelltem Code PM berechnet sich mit der folgender Formel PM ASLOC AT 100 ATPROD siehe auch Abbildung 4 ASLOC automatically generated source lines of code stellt wie der Name bereits sagt die Anzahl der Zeilen dar die automatisch erstellt wurden ATPROD steht f r den Grad der Produktivit t f r die se Codeerstellung Weiters ist ein bestimmter Aufwand f r die Herstellung einer Schnittstelle zwischen dem erzeugten Code und dem restlichen System n tig Da dieser vom prozentuellen Anteil AT des automatisch erstellten Codes abh ngig ist ist auch dies zu ber ck sichtigen SOMMO1 54 159 2 3 3 The Post Architecture Model Das Post Architecture Model also die Stufe nach dem Architek turentwurf ist das detaillierteste der drei Modelle Es sollte dann verwendet werden wenn bereits die Soft warearchitektur festgelegt wurde Einsatz findet das Modell in den Breichen Generierung von Applikatio nen Systemint
327. r zeitlichen Einf hrung am Markt Die immer k rzer werden Release Zeitr ume und die wechselnden Benutzer Bed rfnisse verst rken dies noch 3 1 Wirtschaftliche Aspekte Software Produkte tendieren dazu jedes Jahr um mindestens zehn Prozent zu wachsen 3 Die Alterung einer Software ist dabei besonders von Bedeutung Der optimale konomische Kompromiss zwischen Wartung der existierenden Software und dem optimalen Zeitpunkt f r die Neuentwicklung ist dabei besonders schwer zu eruieren A Neues Release Nutzen Fortf hren eines alten Release Zeit y Abbildung 2 Wartung vs Neuentwicklung Der Grund der wachsenden Wichtigkeit der zeitlich optimalen Freigabe r hrt von dem Fakt dass Software zum richtigen Zeit am Markt mehr Marktanteil und gr eren Gewinn verspricht Dar ber hinaus bedeutet die Ber cksichtigung von Anforderungen von existierenden Kunden in einem neuen Release eine Sicherung des Kundenstammes und ein Vorteil gegen ber der Konkurrenz Ad quate Zeitintervalle zwischen den einzelnen Produkt Freigaben sichert weiters Kundenzufriedenheit in Bezug auf berichtete Probleme und Variabilit t Werden vorgeschlagene Erweiterungen versp tet am Markt positioniert kann dies bedeuteten dass ein Teil der Kunden bereits zu Konkurrenzprodukten abgewandert ist Andererseits kann es aber auch passieren dass wenn ein Produkt zu fr h am Markt erscheint die Kosten den zus tzlichen nderungen gegen
328. rad durch die Testsuite erreicht wurde 5 V sendet das Binary an K und teilt K mit dass D den berdeckungsgrad berpr ft hat Dieser Ansatz hat eine Reihe von Einschr nkungen wie zus tzliche Kosten zeitliche Verz gerungen durch das Einbeziehen eines Dritten sowie die Schwierigkeit des Findens einer passenden von beiden Seiten akzep tierten sogenannten Trusted Third Party Wenn abso lutes Vertrauen gefordert ist und eine vertrauensw r diger Dritter gefunden wurde verlieren die Argumente Kosten und zeitliche Verz gerung aber an Bedeutung Weitere Varianten dieses Ansatzes beschreiben das Testen durch Dritte wobei nur das Binary und nicht der Sourcecode an D bermittelt wird Dabei wird im Be reich des Lieferanten ein Tool eingesetzt das eine kryptografisch signierte berdeckungsmenge gene riert Diese berdeckungsmenge das Binary und die Signatur werden an die Trusted Third Party berge ben die die Signatur berpr ft Der weitere Ablauf entspricht dem oben beschriebenen F r n here Details und weitere Varianten sei auf 5 verwiesen 5 Schlussfolgerung Sowohl die Wieder Verwendung von Software Komponenten als auch das Testen sind bedeutende Bereich in der Softwareentwicklung zur Steigerung der Qualit t Dies wurde versucht in dieser Arbeit zu ver binden vor allem aufgrund der besonderen Problem stellungen in der komponentenbasierten Softwareent wicklung Nach einer kurzen Vorstellung des CBSE und der De
329. rbar als umgekehrt dunkle Figuren werden vor einem hellen Hintergrund schneller erkannt r umlich zentrale Elemente fallen fr her auf als periphere und symmetrische und horizontal vertikal ausgerichtete Figuren erscheinen eindeutiger R umlich oder zeitlich eng zusammen liegende Elemente werden leichter als Einheit betrachtet genau wie einander hnliche Elemente Farbe und Gr e sind hier bedeutsamer als Form Bildet die Anordnung ein kontinuierliches Muster werden die Elemente ebenfalls als zusammengeh rig erkannt Werden die genannten Anordnungsstile vermischt k nnen sie sich unter Umst nden gegenseitig schw chen 3 Die Anordnung der Elemente sollte auch dem logischen Arbeitsablauf Rechnung tragen und zwar noch bevor sie nach Wichtigkeit und H ufigkeit gruppiert werden weiters sollte die Erwartungstreue eingehalten werden gem dem Prinzip Kennt man einen kennt man alle 1 Nicht auszudenken w re die Verwirrung w rde f r die drei Buttons in Windows Fenstern Minimieren Maximieren Schlie en die Reihenfolge ver ndert Bei der Verwendung von Farben sind obige Gruppierungsregeln von hoher Bedeutung meist werden Farben eben zum Zweck der Gruppierung eingesetzt Weiters spiegeln Farben die Dringlichkeit von Elementen wieder auff llige Farben werden eingesetzt um Aufmerksamkeit zu erregen Das Erlernen einer DBenutzeroberfl chke wird durch Farbassoziationen ebenfalls erleichtert Um das Verhalten e
330. rbeugende Aktionen durch zuf hren Dies k nnen etwa die Konzentration von Fehler findungsaktivit ten auf Risikokomponenten sein das Neu designen von jenen Komponenten die h chstwahrscheinlich Fehler verursachen werden oder kostenintensiv zu warten sind oder die entsprechende je nach Risiko Zuteilung von Testressourcen 1 3 Design und Programmierrichtlinien Mit der Hilfe von Softwaremetriken kann ein Unternehmen Richtlinien f r das Design und die Programmierung erlassen Hierbei werden unter anderem Grenzwerte f r die einzel nen Metriken definiert die akzeptable von nicht akzeptablen Werten abgrenzen Softwaremetriken k nnen also dazu ver wendet werden um schlecht geschriebenen Programmcode oder schlechtes Programmdesign aufzuzeigen Aber auch f r Manager sind solche Grenzwerte von Nutzen da extreme Wertabweichungen signalisieren dass m glicherweise Ma nahmen seitens des Managements n tig sind 2 GRUNDLAGEN F R METRIKEN DER OBJEKTORIENTIERUNG Die Grundlagen von objektorientierter Softwaremetriken ba sieren auf den Besonderheiten der Struktur von objektorient ierten Softwaresystemen Da sich diese extrem von prozedu ralen Merkmalen unterscheiden seien hier nun die wichtig sten Merkmale erw hnt und beschrieben 2 1 Kopplung Die Kopplung einer Einheit beschreibt die Wech selbeziehungen die sie zu anderen Einheiten un terh lt und die damit verbundenen Abh ngig keiten 14 Kommunizieren zwei Objekt
331. rds zur Fehlervermeidung bei sicherheitskritischen Systemen und legt somit Qualit tsma st be f r die Industrie fest 4 1 MISRA Guidelines Im November 1994 wurden erstmals die MISRA Guidelines von der MIRA ver ffentlicht die speziell f r Ingenieure Manager und sonstige Involvierte der Automobilindustrie als Unterst tzung und nicht als Vorschrift gelten sollen Hier werden einige Ausz ge aus diesen Guidelines vorgestellt um die Entwicklung von verl sslicher Software so gut es geht zu gew hrleisten Quelle www misra org uk 42 159 Einer der ersten relevanten Punkte besteht in der Differenzierung der zu entwickelnden Software und den anderen Formen des Automobil Ingenieurwesens So m ssen sich die Softwareentwickler zun chst dar ber im Klaren sein dass Software gr ere Kapazit ten umfasst und so auch mehr Komplexit t Im Gegensatz zu den restlichen HW Bestandteilen des Automobils ist SW leicht ver nderbar und auch unber hrbar Makel in der Designphase haben systematische und nicht zuf llig auftretende Softwarefehler zur Folge Eine weitere wichtige Unterscheidung f r die Entwickler besteht allgemein zwischen der Automobilentwicklung und anderen Industriegebieten bez glich der Softwareproduktion da hier das Produktionsvolumen bei weitem gr er ist und es sich um datengetriebene Algorithmen handelt Auch das Fehlermanagement muss bei der Herstellung von Software im Automobil ausgereifter sein da es hier
332. reprojekt lenkung und Verfolgung sowohl mit den technischen als auch mit den programmatischen Aspekten eines Softwareprojekts Auf Stufe 3 stellt das Integrierte Softwaremanagement eine Weiterentwicklung dieser Praktiken an indem zun chst der Softwareprozess der Organisation ber cksichtigt und dann an Projekte angepasst wird Das Softwareprodukt Engineering befasst sich mit der Anforderungsanalyse Design Code und Test In diesem SPB werden ganz konkret das Engineering und die Produktion der Software durchgef hrt Das bedeutet jedoch nicht dass sich die anderen SPBs nicht mit dem eigentlichen Software Engineering besch ftigen Stattdessen bedeutet es dass die meisten Hindernisse f r die konsistente und effektive Produktion von Software sich daraus ergeben wie die Arbeit organisiert ist Und genau dies wird in den anderen SPBs thematisiert Der Zweck der Gruppenkoordination ist einen Mechanismus zu schaffen durch den die Software Engineering Gruppen sich bei den anderen Engineering Gruppen beteiligen k nnen Als Resultat sollten alle Bed rfnisse des Kunden in Bezug auf das gesamte Projekt einschlie lich der Software befriedigt werden Peer Reviews sollen effektiv verhindern dass Fehler bis zu sp teren Schritten im Life Cycle unbemerkt bleiben Der Begriff Peer Review umfasst jede systematische Untersuchung eines Arbeitsprodukts durch einen Kollegen bis hin zu einer sehr formellen Software Inspektion 2 3 F r
333. rf gung Selbstverst ndlich kann dieser Sammelband von Bakklaureats bzw Seminararbeiten keinen wie immer gearteten Anspruch auf Vollst ndigkeit stellen Die Themen reflektieren Inter essensgebiete der im abgelaufenen Semester am Seminar aus Angewandter Informatik teil nehmenden Studierenden Dennoch wurde versucht in der Reihenfolge innerhalb der beiden Gruppen wenigstens den Ansatz eines br chigen roten Fadens zu finden Somit beginnt der Bakkalaureatsteil mit dem finalen Akt der Software Entwicklung einer Arbeit von Ingrid UNTERGUGGENBERGER ber Akzeptanztests Damit dieser positiv verlaufen kann empfiehlt es sich innerhalb des Entwicklungsprozesses nicht blo auf dyna mische sondern auch auf statische Qualit tssicherung zu achten Optionen die daf r bereits in fr hen Entwicklungsphasen bestehen bespricht Ursula DITTRICH in ihrer Arbeit Die for male Inspektion Eine spezielle Review Technik Reviews durchzuf hren setzt freilich voraus dass innerhalb des Entwicklungsprozesses begutachtbare Dokumente entstehen Dies versuchen die in j ngster Zeit propagierten agilen Entwicklungsprozesse zu vermeiden Wie diese die daraus resultierenden Defizite ausgleichen zeigt die Arbeit von Mario GRASCHL Qualitatssicherung bei agiler Software Entwicklung Interessant mag zwischen den Arbeiten Graschls und Unterguggenbergers das Bild des in die Qualit tssicherung involvierten Benutzers bzw Kunden sein Advokaten dieser wie jener Methode si
334. ringen Die so aufbereiteten Daten sind dann auch von Au enstehenden bersichtlicher und leichter zu verstehen Die f nf Arbeitsbereiche in die das Programm unterteilt ist werden in LIDS Defekte Performance Control und Dispersion bezeichnet Die Men s die Macros der Datenspeicher und der Protokoll Bereich befinden sich im LIDS Bereich Die anderen vier Bereiche beinhalten die Modell Charts die als Grundlage f r verschiedene graphische Analysen dienen und ansonsten f r die internen Prozesse des Lotus Inspection Data Systems ben tigt werden Der Benutzer dieses Systems bewegt sich dementsprechend nur im Bereich des LIDS Dort werden die durch die Inspektion gewonnen Daten eingetragen und mit Hilfe des Tools archiviert und ausgewertet Das Tool stellt Funktionen zur Verf gung die dabei behilflich sind die Ergebnisse einer Inspektion wiederum zu reviewen Weiters hilft es dem Benutzer die dabei erarbeiteten Ergebnisse in tabellarische und graphische Form zu bringen LIDS produziert keinerlei druckfertigen Protokolle oder Graphiken pr pariert aber Protokolldaten und kopiert Graphiken in das Windows Clipboard Diese Dateien k nnen dann in vielf ltiger Art und Weise weiterverwendet werden Mit Hilfe der in diesem Tool erstellten Reports k nnen Graphiken wie in Abbildung 7 und Tabellen generiert werden DISPERSION OF EXAMINATION RATE New co id desid of oc tx In ascending size saguence umn ng A 3 pr
335. rkt sich negativ auf deren Verst ndlichkeit aus Dies f hrt zu schlechterer Wartbarkeit und h herer Fehleranf lligkeit Daher sollte man im Allgemeinen eine eher niedrige durchschnittliche Komplexit t anstreben Allerdings sollte man sich keinesfalls alleine auf diese Metrik st tzen da man sonst Gefahr l uft eine un berschaubar gro e Zahl sehr kleiner Methoden zu schreiben 3 3 Vererbung Wenn man objektorientierten Quellcode klassen bergreifend analysiert ergeben sich neue M glichkeiten f r Metriken So finden sich etwa Metriken die sich mit der Vererbungshierarchie der betrachteten Software befassen 3 3 1 Depth of Inheritance Tree Chidamber und Kemerer definierten die OO Metrik Depth of Inheritance Tree DIT 2 als die maximale Entfernung von der Wurzel des Vererbungsbaumes bis zur betrachteten Klasse Die Tiefe einer Klasse in der Vererbungshierarchie hat wesentliche Auswirkungen Je tiefer sie sich in der Hierarchie befindet desto h her ist potentiell die Anzahl an ererbten Methoden und Attributen Dies f hrt zu einer h heren Komplexit t die es erschwert das Verhalten der Klasse korrekt vorherzusagen Eine tiefe Hierarchie bringt eine h here Zahl an Klassen und Methoden mit sich als eine weniger tiefe Aber tiefe Vererbungshierarchien erm glichen daf r potentiell mehr Reuse Es ist also nicht von vornherein klar welche Tiefe des Vererbungsbaums optimal ist 3 3 2 Number of Children Number of Ch
336. rmatierungen sowie die Verwendung bestimmter Utensilien werden mit wach sender Erfahrung wohl aufgegeben werden Eine weitere Schwachstelle Humphreys die vor al lem bei gr eren Projekten zum Tragen kommt ist die v llige Vernachl ssigung der Komplexit t von Aufga ben Hierf r bietet er n mlich keine Methoden wie man die Problemgr e eines Projektes ad quat ermit teln kann Es ist jedoch f r viele Menschen nicht auf den ersten Blick ersichtlich wie komplex ein Projekt ist und wie viel Zeit wirklich f r die Ausarbeitung be n tigt wird 6 Conclusio Zeitplanung ist sowohl im Beruf als auch in der Schule notwendig um qualitativ hochwertige Produkte zu fertigen Vor allem in der Softwareentwicklung ist eine sorgf ltige Planung ausschlaggebend f r den Er folg der Software Erprobte Methoden wie die von Humphrey aber auch Thaller und Ricketts k nnen so fern man sich bei der Entwicklung von Software auch an das Wasserfallmodell oder andere ausgereifte Mo delle h lt eine gewisse Sicherheit bieten dass Projekte fristgerecht und gro teils fehlerfrei fertig gestellt wer den k nnen Das Wasserfallmodell und die daf r entwickelten Entwicklungszeitprozentangaben k nnen vor allem unerfahrenen Projektleitern als Anhaltspunkt dienen Obwohl wir Zeitmanagement als sinnvoll erachten werden sich die Methoden von Humphrey nur schwer innerhalb des Informatikunterrichts unterbringen las sen da der Lehrplan nur wenige
337. roduktes sind 3 2 3 Software Hardware Umgebung und Ressour cen Der Akzeptanztestplan sollte die Hardware und Softwareumwelt identifizieren die ben tigt wird um das Produkt zu testen Zus tzlich k nnte der K ufer die Unterst tzung des Verk ufers zur Konfiguration des fertigen Softwareproduktes oder der Hard ware Software Umgebung des Abnahmetests gebrau chen 3 2 4 Akzeptanzkriterien Der K ufer k nnte Schwierigkeiten mit der Identifikation der Akzeptanz kriterien f r das Produkt haben Das kann einerseits am Erfahrungsmangel des K ufers liegen oder aber auch an einem eingeschr nkten Verst ndnis f r das fertige Produkt Der Verk ufer kann dem K ufer bei der Entwicklung der Kriterien helfen Diese Hilfe minimiert Missverst ndnisse die das Bestehen der einzelnen Abnahmekriterien betreffen Der K ufer muss allerdings beachten dass er trotzdem allein ver antwortlich f r die Genauigkeit der Kriterien ist Dazu kommt dass wenn Zeitplan und Budgets einmal auf Grund dieser Kriterien aufgestellt wurden alle Ausga ben des Verk ufers die durch nachtr gliche nderun gen an den Akzeptanzkriterien entstehen vom K ufer getragen werden m ssen Genau beim Punkt der nachtr glichen nderung von Anforderungen kommt noch ein zus tzlicher Aspekt dazu Extreme Programming kurz XP XP l sst sich mit einem Puzzle vergleichen Kunden und Entwickler sind Teil eines Teams dessen Ziel es ist hochqualitative Software zu
338. rozesses der Erstellung eines Verhaltensmodells werden s mtliche Erwartungen der Benutzer in das Verhalten des Systems integriert Trotzdem auftauchende Unterschiede zwischen den Erwartungen der Benutzer beziehungsweise ihren Gedankenmodellen und dem Verhaltensmodell des Programms k nnen dann ausgehend vom Verhaltensmodell behoben werden Zur Anwendung kommen kann und soll es berall dort wo es n tig ist das Verhalten des Programms zu kennen beispielhaft sind hier Dokumentation und Hilfestellungen 14 Partizipation von Benutzern in die Entwicklung eines Softwareprojekts ist heutzutage selbst im Falle von Produkten f r anonyme Benutzer schwer wegzudenken hier k nnen beliebige unbefangene Personen als Tester dienen blich ist das Einbeziehen der Benutzer in die Anforderungsanalyse und die Testphase dar ber hinaus ist ihre Beteiligung an allen anderen Phasen ebenfalls m glich und in einigen Modellen blich Ideal w re es s mtliche bekannte und potenzielle Benutzer einzubeziehen teilweise im Internet blich realistischer ist die Einbeziehung von repr sentativen Benutzergruppen Nicht immer sind einbezogene Benutzer freundlich gesinnt Sicherheitsfirmen bedienen sich fter verschiedener Angreifer die sich zur Verf gung stellen m ssen um dem Gef ngnis zu entgehen Fragw rdig ist in diesem Fall ihre Glaubw rdigkeit aber ein nicht krimineller Tester w re aufgrund seiner unangemessenen Grundeinstellung kaum n tzlich
339. rpunkt aber liegt auf den neuen OO Metriken die in den letzten Jahren vorgeschlagen wurden Hier sind vor allem die Metriken von Chidamber und Kemerer von Interesse weil diese die Grundlagen f r viele weitere Entwicklungen auf diesem Gebiet schufen Im vorletzten Kapitel werden f r den praktischen Einsatz von Metriken einige freie Tools f r die Programmiersprache Java vergestellt Den Abschlu bildet eine Auseinandersetzug mit zwei wesentlichen Kritikpunkten an Software Metriken 1 Einleitung Die Grundlagen f r das Gebiet der Software Metrikent wurden in den 60er und 70er Jahren gelegt In den Naturwissenschaften ln englischsprachiger Literatur wird neben dem Begriff software metric auch gelegentlich software measurement synonym dazu verwendet hatte die Messtechnik bereits eine lange Tradition und war zu einem unverzichtbaren Hilfsmittel f r die Forschung geworden Man erhoffte sich mit Messungen auch in der Informatik neue Erkenntnisse zu gewinnen und Werkzeuge f r die Softwareentwicklung zu schaffen Seit jenen Anf ngen sind dazu unz hlige Metriken vorgeschlagen worden Diese sollen uns unter anderem dabei helfen bessere Aufwandsabsch tzungen zu treffen den Projektfortschritt zu messen Komplexit t richtig einzusch tzen und nicht zuletzt Qualit t zu messen und zu verbessern 6 Mit der Durchsetzung des objektorientierten Paradigmas in den letzten Jahren entstanden auch neue Metriken die die Objektor
340. rsprache R cksicht nehmen Verdeutlicht wird dies in einem sp teren Kapitel da sich mit Werkzeugen die Metriken f r Source Code in der Programmiersprache Java berechnen befa t 2 Klassische Metriken Bevor wir uns mit den OO Metriken befassen sollen hier klassische Metriken aus Zeiten der strukturierten Programmierung vorgestellt werden Diese Metriken sind zwar urspriinglich nicht f r objektorientierte Software ausgelegt worden aber das bedeutet noch nicht zwangsl ufig da sie deswegen nicht mehr anwendbar und daher uninteressant w ren 2 1 Lines of Code Die Metrik LOC ist wohl die lteste Software Metrik Es gibt sie in unterschiedlichen Varianten Die einfachste ist alle Zeilen im Code gleich zu z hlen egal ob es sich um Kommentarzeilen Leerzeilen oder Zeilen mit Programmcode handelt Diese Art der Z hlung wird allerdings eher nicht verwendet wenn die Komplexit t und Programmgr e gemessen werden soll und Kommentarzeilen hierf r nicht relevant sind Mi t man nur Zeilen die auch Code enthalten so spricht man von SLOC Source Lines of Code 7 oder eLOC Effective Lines of Code 8 SLOC ist meistens gemeint wenn man von Lines of Code spricht Eine weitere Variante von LOC ist die Metrik LLOC Logical Lines of Code die nur Zeilen mit Statements z hlt Dabei wird gern genutzt dass viele Programmiersprachen ihre Statements mit Strichpunkten beenden Also werden einfach nur diese Zeilen gez hlt in de
341. rtung und Aufbereitung der definierten Tests zust ndig Bei den unterschiedlichen Methoden der agilen Software entwicklung ist es durchaus m glich dass Tester die fast origin re Form ihrer T tigkeit aus ben und in einer eigenen Testphase Testf lle generieren und pr fen Bei XP hingegen ist die Rolle des Testers durch den Prozess neu zu definieren und eher als Qualit ts sicherungsverantwortlicher zu sehen 7 Fazit Agile Softwareentwicklung beschreitet im Gegen satz zum traditionellen Ansatz einen vollkommen anderen Weg wie Software entwickelt werden kann Diese Art von Entwicklung macht zwar keine voll kommen neue Art von Qualit tssicherung notwendig aber beeinflusst die Art wie Qualit tssicherung betrie ben wird Im agilen Ansatz wird die Qualitatssicherung verstarkt als ein Instrument zur Uberpriifung der Kundenanforderung gesehen und beeinflusst damit direkt die Qualit t des Produktes Die unterschiedliche Art der Qualit tssicherung liegt nur im Fokus der Qualit tssicherung Tests werden genauso wie beim traditionellen Ansatz eingesetzt ebenso Dokumentation und Reviewing Die Entscheidung welche Art von Prozess verwendet werden soll ist von anderen Faktoren abh ngig n mlich von der Projektgr e und ob eine bestimmte Methoden betrieben werden muss Agile Softwareentwicklung ist f r die Entwicklung von kleinen und mittleren Projekten gut geeignet besonders aber f r die Entwicklung von Einzell sungen wie zum Be
342. s 5th Workshop on Software Metrics Berlin 1995 URL http irb cs tu berlin de Zuse gi erni ps gz 13 B Kahlbrandt Skript zur Vorlesung Software Engineering II URL http users informatik haw hamburg de khb st4se2 node146 html 2001 14 K Kuhlmann Komplexit t Kopplung und Bindung bei der objektorientierten Softwareentwicklung 5th Workshop on Software Metrics Berlin 1995 URL http irb cs tu berlin de zuse gi kuhlmann ps gz 15 M Lorenz J Kidd Object Oriented Software Metrics Prentice Hall Englewood Cliffs New Jersey 1994 16 S Whitmire Object Oriented Design Measurement John Wiley amp Sons Inc 1997 17 M Xenos D Stavrinoudis K Zikouli D Christodoulakis Object Oriented Metrics A Survey Proceedings of the FESMA 2000 Federation of European Software Measurement Associations Madrid Spain 2000 URL http edu eap gr pli plil0 info xenos Personal page files C14 Object Oriented Metrics a Survey pdf 18 H Zuse Properties of Object Oriented Software Measures Proc 7th Annual Oregon Workshop on Software Metrics 1995 19 H Zuse A Framework of Software Measurement de Gruyter Publ 1998 Der optimale Software Release Zeitpunkt Daniel Peintner Mat Nr 98 30 851 daniel peintner edu uni klu ac at Abstract Steigender Konkurrenzkampf in der Software Industrie sich st ndig ndernde Bed rfnisse der Kunden gepaart mit Pflege der Software haben das Timing von
343. s der korrekte Gebrauch des Traceability Mittel zum Zweck ist um die volle Steuerung zu haben und zu zeigen dass alles l uft W hrend der Designphase verwendet der Pro jektmanager das Traceability um dem Top Management die M glichkeit der Nachvollziehbarkeit zu gew hrleisten Es hilft ihm auch Projektverz ge rungen fr hzeitig zu erkennen und somit gegenzusteu ern 4 2 3 Systemdesigner und Systemtechniker Der bedeutendste Gebrauch von Traceability w h rend eines Projektes wurde durch das Notizbuch des Systemdesigners beobachtet Die gesammelten Daten die in freier Textform notiert wurden erfordern vom Systemdesigner ein gro es Ma an Disziplin um rati onal zu erkl ren warum das System designt wurde wie es ist Diese Informationen k nnten Unsch tzbares w hrend der Life Cycle Wartung und bei der Entwick lung hnlicher Systeme pr fen Obgleich das Projekt nicht in dem Stadium der Wartung ist sieht der Sys templaner weitgehend die Ver nderungen an den Co demodulen und unterlagen voraus WST Weapon System Technology Support Branche eine amerikanische DoD Organisation an der McClellan Air Force Base 4 2 4 Tester Die Systemtester planen die Verwendung von Tra ceability wenn sie den Plan f r den Akzeptanztest schreiben Unter der Verwendung des Traceability Tools berpr fen die Tester ob der Akzeptanztest alle an das System gestellte Anforderungen erf llt um somit jene Vollst ndigkeit un
344. s f hrt jedoch wiederum dazu dass viele Sch ler lehrergerechte Aufzeichnun gen anfertigen die wenig mit dem tats chlichen Auf wand des Sch lers gemein haben Weiters wird es schwierig sein Sch ler aber auch Kollegen dazu zu motivieren ihre alten Muster der eher intuitiven Zeitplanung aufzugeben Trotz des anf nglichen hohen Gesamtaufwandes sollte man die Eltern Kollegen und Sch ler dennoch von der Notwendigkeit der vorgestellten Methoden berzeugen da heute in vielen Berufsfeldern Teamar beit und projektorientiertes Arbeiten unter harten zeit lichen Grenzen gefordert ist Sch ler denen ein fun diertes Wissen bez glich Zeitmanagement z B durch Projektunterricht rechtzeitig vermittelt wird werden in der Lage sein mit gr eren Projekten ad quat um zugehen Wenn man bereits beruflich in den Softwareent wicklungsprozess eingebunden ist werden wahrschein lich hnliche Probleme wie in der Schule auftreten Man braucht nur Lehrer durch Vorgesetzten oder Projektleiter und Sch ler durch Mitarbeiter zu ersetzen Sofern der Manager davon berzeugt ist dass quali tativ hohe Software der individuellen Zeitplanung je des Mitarbeiters bedarf wird er jedoch Methoden des Zeitmanagements einsetzen Hierbei werden die doch sehr allgemeinen Metho den von Humphrey wohl vermehrt auf die Bed rfnisse der Firmen angepasst werden m ssen Auch rigide vor geschriebene Layouts und Fo
345. schlussendlich im Ergebnis der Arbeit wieder spiegelt 3 L sungsans tze Dieser Abschnitt wird sich damit befassen L sungsm glichkeiten f r die im vorigen Abschnitt beschriebenen Probleme vorzustellen 3 1 Knowledge Scouts Als L sungsm glichkeit der Probleme Fremdheit und kulturelle Unterschiede erweisen sich die von Dutoit Johnstone und Bruegge 1 als Knowledge Scouts bezeichneten Mitarbeiter Diese Mitarbeiter arbeiten eine kurze Zeitspanne in einem Projektteam an einem anderen Standort Dabei lernen sie die dortigen Mitarbeiter sowie die dortige Kultur kennen Dadurch werden Kommunikationsbarrieren berwunden und ein globales Teamgef hl erzeugt Diese Knowledge Scouts bilden die Bindeglieder der einzelnen Teams untereinander Sie bringen dem fremden Team die Arbeitsweise und die Mitglieder ihres eigenen Teams n her Nach ihrer R ckkehr geben sie ihr Wissen ber das fremde Projektteam ihren Kollegen weiter Dieses gegenseitige Kennen lernen f rdert die Kommunikation zwischen den Teams Nach dem Besuch des Knowledge Scouts steigt die Kommunikation zwischen den beiden Teams und somit auch die Qualit t der Arbeit 3 2 Standards Standards werden in allen Projekten definiert Ihre besondere Bedeutung in globalen Projekten bekommen sie da weder die formelle noch die informelle Kommunikation zwischen den einzelnen Projektteams Zeit hat sich allm hlich zu entwickeln Es ist ratsam auch Standards f r verschieden
346. se nderungen durchgef hrt werden sehr hoch ist F r Stabilit t konnte Martin zwei wesentliche Indikatoren identifizieren Stabile Klassen haben keine Abh ngigkeiten zu instabilen Klassen Klassen die berhaupt keine Abh ngigkeiten haben bezeichnet Martin als Independent Klassen von denen viele andere Klassen abh ngen k nnen nur schwer ge ndert werden Daher gelten sie auch eher als stabil Solche Klassen nennt Martin Responsible Am stabilsten sind nach seiner Auffassung Klassen die beides Independent und Responsible sind Ein weiterer wichtiger Aspekt f r Martins Metriken ist die Bildung von Klassen Gruppen oder Packages In Packages sind Klassen mit hoher Koh sion zueinander gruppiert Diese Koh sion l t sich am Grad der Kopplung erkennen nderungen einer Klasse in einem Package d rfen zu nderungen in anderen Klassen des gleichen Package f hren aber nicht zu Ver nderungen in anderen Packages Klassen die ein Package bilden sollen zusammen reused werden Martin transferiert die Idee der Koh sion von der Ebene einzelner Klassen Kapitel 3 1 auf die Package Ebene Weiters argumentiert er da nun eigentlich die Abh ngigkeiten zwischen den Packages entscheidend sind und bertr gt auch seine Definition von Stabilit t Independent und Responsible auf Packages Schlie lich definiert Martin vier Metriken e Afferent Couplings Ca Anzahl der Klassen au erhalb des Packages
347. se Quantit t Qualit t Pro jektdauer und Produktivit t ber cksichtigen KNOE91 Au erdem spricht f r COCOMO dass es gut do kumentiert ist sowie haufig verwendet und ausgewertet wird Des Weiteren ist es frei verf gbar und wird von Public Domain und kommerziellen Werkzeugen unter st tzt SOMMO1 Aus verschiedenen Gr nden die in Kapitel 2 1 n her ausgef hrt werden sollen kam es zu einer berar beitung des urspr nglichen Modells das heute COCOMO 81 genannt wird und zur Neuentwicklung und Ver ffentlichung im Jahr 2000 von COCOMO II 2 1 Von COCOMO zu COCOMOU Mittels empirischen Untersuchungen erkannte Bar ry Boehm einen funktionalen Zusammenhang zwi schen Systemgr e nach Anzahl der Codezeilen und dem Erstellungsaufwand Da eine derartige Gleichung keine zufriedenstellenden Ergebnisse lieferte ber ck sichtigte er zus tzlich Einflussfaktoren f r Qualit tsan forderungen und Produktivit t Auf diesem Wege ent stand COCOMO KNOE91 Je nach Entwicklungskomplexitat und schwierigkeit gibt es bei COCOMO 81 BOEH00 wie das urspriingliche Modell heute genannt wird drei Berechnungen Man unterscheidet hier zwischen ein fach basic mittel intermediate und detailliert detai led Ausgangspunkt f r die Sch tzung ist die Gr e des Projektes also die Sch tzung der Anzahl der ben tigten Codezeilen in KDSI kilo delivered source in struction Mit Hilfe einer Formel werden dann die Personenmon
348. se am Erfahrungs austausch ber die der neuen Rechtslage entsprechen den Form von Bakkalaureats Seminaren besteht m ch te ich in diesem Aufsatz die dabei gewonnenen Erfah rungen der Kollegenschaft bermitteln Es liegt an den n chsten Seminarleitungen in wie weit das hier ge w hlte Modell aufgegriffen wird ob es in modifizierter Form zum Einsatz kommt oder ob v llig andersartige Durchf hrungsformen erprobt werden Da Konferenzseminare nicht zum seminaristischen Standardrepertoire geh ren m chte ich in der Folge diese Organisationsform allgemein beschreiben und anschlie Rend auf die f r dieses Seminar spezifische Variante eingehen Dies bedeutet dass nach Schilderung der Aus gangsbedingungen der konkrete Seminarablauf und die dabei gewonnenen Erfahrungen dargestellt werden Eben so werden die wesentlichsten Elemente des studentischen Feedbacks referiert 2 Organisationsform Die Idee Seminare als Konferenzseminar durchzu f hren wurde von H Pirker in einem im Rahmen der OOPSLA 1999 abgehaltenem Workshop ber educat ional patterns aufgegriffen und nach Klagenfurt gebracht Sie stie auf Interesse der Forschungsgruppe Software Engineering und demgem fanden die Spezialseminare aus Software Engineering in den Wintersemestern der letzten vier Studienjahre als Konferenzseminare statt Unter Konferenzseminar ist dabei zu verstehen dass Studierende auf der Basis eines Rahmenthemas Konfe renzthema in Beantwortu
349. sen die Drehgeschwindigkeit und l sen gegebenenfalls die Bremse um ein Blockieren zu verhindern so den Bremsweg zu verk rzen und die Lenkbarkeit des Fahrzeuges noch m glich zu machen Das ESP Elektronisches Stabilit ts Programm ist eine weitere Entwicklung die schon so manches Menschenleben retten konnte Daten aus Lenkwinkelsensoren am Lenkrad werden mit den Daten aus Raddrehzahlsensoren verglichen und so kann die SW erkennen in welche Richtung der Fahrer sich fortbewegen will Entspricht aber die tats chliche Fahrtrichtung sei es Aufgrund von Eis oder Schnee nicht die der gew nschten greift die Software in einem Bruchteil einer Sekunde in das Brems und Motormanagement ein um so ein Schleudern zu verhindern Diese angef hrten Beispiele sind sicherheitskritische bzw life critical Softwaresysteme wobei dagegen der Einsatz von einer elektrischen Versperreinrichtung Anstelle eines Schl ssels f r das Automobil unter die Komfortsysteme f llt Die Liste der verschiedenen Software Systeme im Automobil ist damit aber noch lange nicht vollst ndig 40 159 doch die Aufz hlung aller vorhandenen Einrichtungen w rde hier den Rahmen weit sprengen und soll nicht Thema dieser Arbeit sein Der Einsatz der oben genannten Software Techniken kann in der Praxis jedoch oft nicht nur positive Auswirkungen haben Abgesehen von den Fehlfunktionen die Aufgrund der hohen Komplexit t auftreten k nnen ist bei diesem Softwareumfan
350. setzt werden k nnen Die Frage ob der Einsatz dieser Qualit tssicherungsmethode berhaupt wirtschaftlich ist werde ich in dem darauf folgenden Kapitel beantworten und dann auf die Vor und Nachteile der Inspektion eingehen Daraufhin werde ich kurz das Lotus Inspection Data System vorstellen das eine M glichkeit bietet die Ergebnisse einer Inspektion zu erfassen zu archivieren und zu analysieren Abschlie en werde ich meine Arbeit mit einer kurzen Zusammenfassung der behandelten Themen und einer pers nlichen Schlussfolgerung beenden 2 Review allgemein IEEE definiert ein Review als ein formelles Treffen bei dem ein Produkt oder Dokument dem Benutzer Kunden oder anderen interessierten Personen vorgelegt wird um es zu kommentieren und abzusegnen IEEE 1990 Reviews Software Requirements Review Premliminary Design Review Critical Design Review rn 1 in Process Review s Management Review Fagan Inspection Code Walkthrough Technical Review Abbildung 1 Arten von Reviews Thaller 2000 Je nach Anwendungsbereich existieren zahlreiche verschiedene Ans tze f r Reviews die mit bzw ohne Kunden stattfinden und in definierten Phasen zum Einsatz kommen Reviews sind T tigkeiten die innerhalb eines Projektteams angewandt werden um Fehler zu finden Das Ziel ist neben der eigentlichen Fehlerfindung der Zeitpunkt der Fehlerfindung Je fr her ein Problem erkannt und korrigiert wird desto ger
351. sind Bei einer gr eren Zeitverschiebung sind diese Zeiten jedoch sp rlich bis berhaupt nicht vorhanden Im Extremfall gibt es keine gemeinsamen B rostunden Somit ist synchrone Kommunikation auf vorher festgelegte Zeiten beschr nkt Ein Team das an dieser Kommunikation teilnimmt muss daf r berstunden machen Dies kann zu Ressentiments gegen ber dem anderen Team f hren die erst abgebaut werden m ssen Asynchrone Kommunikation ist jederzeit m glich erfordert jedoch Zeit Eine Antwort ist erst am n chsten Werktag zu erwarten Ein weiterer Nachteil von asynchroner Kommunikation ist die damit verbundene Qualit tsminderung Verst ndnisprobleme erfordern Zwischenfragen die bei asynchroner Kommunikation unm glich sind Das Ausarbeiten von Kompromissen ist mit asynchroner Kommunikation zeitlich unm glich da es eine allm hliche Ann herung der Standpunkte erfordert 2 4 Kulturelle Probleme In diese Kategorie fallen nicht nur Unterschiede in der gelebten Kultur und Sprachprobleme sondern auch Unterschiede in der Unternehmenskultur der verschiedenen Projektteams Einer der heikelsten Punkte bei verteilten Projekten ist die Sprachbarriere Die Projektteilnehmer m ssen in der Lage sein fachliche Diskussionen in einer f r sie fremden Sprache zu f hren Dies erfordert nicht nur gute allgemeine Kenntnisse in der Sprache sondern auch das entsprechende Fachvokabular Die Sprachbarriere kann gerade bei Fachausdr cken zum
352. sind hier die Wiederholbarkeit von Tests und die M glichkeit Unzufriedenheit speziellen Bereichen und Benutzergruppen zuzuordnen Gause und Weinberg 5 empfehlen hier die Benutzer selbst die Testkriterien bestimmen zu lassen und Kommentare bei der Auswertung der Testb gen ernst zu nehmen Vor allem Prototypen 79 159 eignen sich zum Testen von Zufriedenheit hervorragend sie lassen Schl sse auf das zuk nftige Verhalten der Benutzer am fertigen System zu Eine weitere Methode um Zufriedenheit verl sslich zu bestimmen oder gar zu lenken ist die Einbindung der Benutzer nicht nur in die Spezifikation und den Test sondern auch in den Entwurf siehe die ETHICS Methode die in einem sp teren Kapitel noch genauer beschrieben wird 2 3 Beteiligte Die erste Frage die zum Thema Benutzer zu kl ren ist ist wer diese Benutzer eigentlich sind Zuerst muss zwischen Kunde und Benutzer unterschieden werden denn der Kunde ist nur die Person oder Organisation die zahlt der Benutzer hingegen wird lange Zeit von dem Produkt betroffen sein Sie unterscheiden sich in Erwartungen und Macht denn obwohl der Kunde mehr Einfluss hat da er ja zahlt hat der Benutzer meist die h heren Erwartungen und wird sich im Gegensatz zum Kunden nicht immer mit der Erf llung des Pflichtenhefts begn gen Zus tzlich zu Kunden werden auch die Benutzer h ufig in den Entwicklungsprozess einbezogen anfangs bei der Anforderungsanalyse und am Ende bei Tests
353. siskonzept und Manifest der agilen SE Die wesentliche Strategie die bei der agilen Soft wareentwicklung betrieben wird ist das Prinzip der Einfachheit womit auf nderungen so einfach wie m glich reagiert werden kann Generell wird ein evolution r inkrementelles Vorgehen angewandt nicht un hnlich der Entwicklung eines Prototyps Beim traditionellen Ansatz liegt der Fokus auf der Dokumentation bei der agilen Softwareentwicklung hingegen tritt an diese Stelle die Kommunikation Umfangreiche Dokumentation ist weitaus weniger wichtiger als das Gespr ch zwischen allen Beteiligten Diese Ansicht wird innerhalb der Verfechter der agilen Methoden soweit betrieben dass der Quellcode einer Software als Dokumentation angesehen wird Diese Fokussierung auf Kommunikation bedeutet dass Kunde Entwickler und andere Projektbeteiligte im st ndigen Kontakt zueinander stehen Dies bedeutet dass alle Beteiligten einen aktuellen und hohen Wissensstand ber das Projekt besitzen Des Weiteren tritt anstatt der Orientierung an den Prozess eine Ori entierung an das Team so dass die Planung in den Hintergrund und die Zielorientierung in den Vorder grund gestellt wird 8 Um dieses Basiskonzept auch niederzuschreiben wurde ein Manifest der agilen Softwareentwicklung geschaffen 9 10 Diesem Manifest verpflichten sich alle Entwickler die agile Methoden einsetzen Das Manifest ist eine Sammlung von Grunds tzen die die Grundidee der agilen Soft
354. sollen On Board Diagnosesystem OBD System bezeichnet ein an Bord des Fahrzeugs installiertes Diagnosesystem f r die Emissions berwachung das in der Lage sein muss mit Hilfe rechnergespeicherter Fehlercodes Fehlfunktionen und deren wahrscheinliche Ursachen anzuzeigen 7 Diese OBD Systeme liefern Informationen zur Fehleridentifikation und sollen den Kunden so lange es geht mobil halten indem sie drei verschiedene Arten von Fehlern vermeiden sollen e Nichtexistierende oder unkorrekte Sensorensignale e Bestimmte SW Komponenten die nicht wie erwartet handeln e Prozesse des Hostsystems die nicht funktionieren aber deren Ausl ser nicht im Prozessor selbst liegen Wurde nun einer dieser Fehler w hrend des Betriebes gefunden so l st das Diagnosesystem folgende 44 159 Reaktionen aus Der Fahrer wird gewarnt Fehlerdaten werden gespeichert es wird auf Sparflamme geschaltet bis zur Reparatur und lokale Fehlermeldungen werden ausgegeben Wichtig bei diesen Aktionen ist f r das System die Unterscheidung zwischen schweren und kleineren Fehlern deren Relation vom Entwickler festgelegt werden muss On board diagnostics sollen laut MISRA nachtr glich in das Gesamtsystem eingebaut aber auf keinen Fall vergessen werden Bei der Programmierung selbst ist besonders darauf zu achten welche Sprache man verwendet Durch die Schwierigkeit Maschinencodes nachzuvollziehen und diese dynamisch zu ver
355. sollte man wegen dieser Untersuchung nicht gleich davon ausgehen dass diese Metrik eindeutig die beste Koh sionsmetrik ist Der gleiche Versuch mit anderen Klassenbibliotheken oder anderen Experten k nnte relativ stark abweichende Ergebnisse liefern Ein Problem der Validierung selbst ist das unstandardisierte und in Folge teilweise sehr unterschiedliche Vorgehen Bem hungen die Vorgehensweisen zu vereinheitlichen unternahmen u a Briand Emam und Morasca 21 Sie identifizierten 2 Arten der Validierung die beide notwendig sind und einander erg nzen sollen a Theoretische Validierung Bei dieser Art der Validierung wird berpr ft inwieweit die Metrik tats chlich mit der 14U a alle in Kapitel 3 1 erw hnten 64 159 Eigenschaft korreliert die sie laut ihrem Erfinder messen soll b Empirische Validierung Diese Validierung konzentriert sich auf den Nutzen der Metrik in der Praxis In die empirische Validierung flie t daher mit ein wie die Metrik tats chlich eingesetzt wird Auch von anderer Seite wie zB von Kitchenham et al wird versucht die Validierung von Metriken zu standardisieren Von ihr wird ein Framework for Software Measurement Validation 22 vorgeschlagen Die Entwicklungen im Bereich der Metriken Validierung sind vielversprechend und geben Grund zur Hoffnung dass die bereits vorhandenen und auch neue Metriken m glichst objektiven berpr fungen unterzogen werden Au erdem so
356. spezielle Art des Reposi tory Designs vor Softwarekomponenten m ssen so abgelegt werden dass ein leichtes Auffinden und Wie derverwenden m glich ist Zus tzlich muss jeder Komponente eine Person oder ein Team zugeordnet werden die das f r die Wartung verantwortlich ist Dass sich die Entwickler streng an Interface Standards halten ist dabei wesentlich F r jede Komponente m ssen mehrere Artefakte gespeichert und st ndig aktuell gehalten werden e Die Spezifikation inklusive Referenzen zwischen Requirements und deren Implementierung Wenn im Code bzw der Spezifikation nderungen ge macht werden muss diese nderung im entspre chenden bereinstimmenden Dokument nachgezo gen werden e Die Test Suite inklusive Querverbindungen zwi schen den Test F llen und den Code Teilen die damit getestet werden sollen Neue Funktionalit ten f hren zu neuen Test F llen in der Test Suite Dies erleichtert die Auswahl der Test F lle eines Regressionstests e Pointer zwischen der Spezifikation und den Teilen der Test Suite die diese Funktionalit ten validie ren Dies zeigt in welchem Ausma bestimmte Tei le der Spezifikation in der Test Suite ber cksichtigt werden 129 159 Auf alle F lle sollte eine Test Suite m glichen In put und erwarteten Output enthalten Dies erleichtert den Regressionstest nach nderung der Komponenten 4 2 Maturity Model f r den Komponenten Test Prozess Um die Effektivit t der Testpro
357. ssen ableiten Durch Kombination der drei oben genannten In formationsquellen kann nun ein sinnvolles und exakt definiertes Goal bestimmt werden Die Questions die nun ausgehend von den Goals abgeleitet werden stellen eine Verfeinerung dieser dar W hrend die Goals sehr abstrakt definiert sind sollen die Questions diese konkretisieren und die M glichkeit zur Interpretation geben Durch Be antwortung der Questions soll schlussendlich festge stellt werden ob ein definiertes Goal erreicht wurde Es ist also wichtig w hrend der Erstellung der Questions immer wieder zu verifizieren ob sie wirklich zur Evaluierung des Goals beitragen Auf Basis der abgeleiteten Questions werden ad quate Metriken bestimmt welche die quantitativen Informationen liefern durch die die Questions be antwortet werden k nnen Bei der Auswahl der Metri ken sollte darauf geachtet werden wie schwierig es ist diese in den Projektablauf einzubinden Im GQM Plan ist der oben beschriebene Ablauf dokumentiert Au erdem erstellt man in der Definiti onsphase einen Messplan Dieser definiert f r jede der identifizierten Metriken die Art der Messung die Per sonen welche die Messung durchf hren die Tools die zur Unterst tzung verwendet werden und alle m gli chen Werte die durch eine spezifische Messung zu r ckgeliefert werden k nnen Der Analyseplan simuliert schlussendlich die Inter
358. st Traceability Vorhandene Unterst tzung liefert haupts chlich Post Traceability Alle m glichen Probleme sind ein Artefakt der formlosen Entwicklung von Methoden Diese k nnen durch formale Entwicklungseinstellun gen beseitigt werden wenn sie automatisch in eine ausf hrbare RS transformiert werden k nnten sie ist aber ohnehin nur schwer verwendbar Demgegen ber steht die Aussage dass Pre Traceability nur schwer verst ndlich ist und die Nachvollziehbarkeit nicht bzw nur schlecht unterst tzt Es ist argumentiert worden dass Probleme des Pre Traceability ungeachtet der formalen Behandlung bleiben da dieser Aspekt des Lebens einer Anforderung in sich selbst Paradigma unabh ngig ist 1 4 Requirements Traceability Meta Model Nachdem nun ein kurzer Ein und berblick ber die einzelnen Arten des Traceability gegeben wurde ist es nun an der Zeit sich etwas n her mit dem Meta Modell zu besch ftigen Der Bedarf eines besseren Verst ndnisses des Traceability ist weitgehend be kannt Hierzu wurde von einigen Institutionen aufge zeigt welche Punkte bei der Entwicklung eines sol chen Meta Modells zu beachten sind 4 1 Eigenschaften des Meta Modells Laut der Ver ffentlichung des Papers Issues in the Development of a Model of Traceability von den Autoren Ramesh und Edwards sind folgende Punkte zu ber cksichtigen 9 REQUIREMENTS STAKEHOLDER y Abb 6 Requirements Traceability Meta Model 9
359. stellen Ein Ansatz daf r sind die von J ron et al vorgestellten Test Dependency Graphs 6 die eine Erweiterung von UML Klassendiagrammen sind Diese haben den Nachteil dass nicht erkennbar ist welche Art der Abh ngigkeit zwischen zwei Klassen vorliegt Ein anderer von Kung et al vorgestellter Ansatz der Klassenzusammenh nge explizit macht sind Objekt Relations Diagramme ORDs 2 In der vorliegenden Arbeit wollen wir ORDs vorstellen und zeigen wie sie den Testprozess verbessern k nnen Alle angef hrten Beispiele sind in Java geschrieben allerdings sind die Konzepte nicht auf diese Sprache beschr nkt 132 159 2 Probleme des objektorientierten Testens Durch die komplexen Klassenzusammenh nge in objektorientierten Programmen ist das Testen und die Wartung eine anspruchsvolle Aufgabe Daf r gibt es folgende Gr nde 2 e Es ist schwierig Klassen in gro en Programmen zu verstehen wenn diese von vielen anderen Klassen abh ngen e Ohne einen geeigneten Einblick in den Programmaufbau wissen Tester oft nicht bei welchen Klassen der Testprozess begonnen werden soll e Das Schreiben von Stubs ist zeit und damit kostenintensiv Bei Experimenten wurde ermittelt dass der Zeitaufwand f r das Schreiben eines Stubs im Durchschnitt zwischen einer halben Stunde und einer Stunde liegt 1 e Der Einfluss von Polymorphismus Laufzeitverhalten ist schwer abzusch tzen e Die Auswirkungen von Programm Anderungen pflanz
360. stems Die Explorati onsphase dauert in der Regel zwischen ein paar Wo chen und ein paar Monaten abh ngig von der Pro jektgr e und der Vertrautheit mit den eingesetzten Tools Die Planning Phase dauert ein paar Tage und beinhaltet die Planung der einzelnen Storycards Des Weiteren wird in dieser Phase eine Vereinbarung mit dem Kunden getroffen welche Funktionalit ten die erste Version der zu entwickelnden Software zur Verf gung stellen soll In der Interations to release Phase wird nun diese erste Version entwickelt Diese Phase beinhaltet mehrer Zyklen die in der Regel bis zu vier Wochen dauern k nnen Die erste Iteration liefert die Architektur des Systems Danach wird vom Kun den ausgew hlt welche Storycard bei der n chsten Iteration implementiert wird diese Version wird an hand von Kundentestf llen gepr ft Nach der letzten Iteration ist das Produkt fertig f r die n chste Phase In der Productionizing Phase wird die Software weiteren Tests unterzogen Innerhalb dieser Phase k nnen neue Kundenanforderungen identifiziert wer den Hier muss die Entscheidung getroffen werden ob diese Anforderungen in die bestehende Version einge baut werden dies bedeutet ein erneutes durchlaufen von Iterationen oder ob diese Anforderungen erst w h rend der n chsten Phase implementiert werden diese Anforderungen m ssen auf jeden Fall dokumentiert werden Nachdem das Produkt diese Phase bew ltigt hat wird das Produkt a
361. sten im Gegensatz zu herk mmli chen Methoden eine zentrale Rolle einnimmt Dies besonders dadurch dass die Kundeneinbindung ein Teil der Qualit tssicherung geworden ist Weitere nennenswerte Rollen innerhalb des Teams w ren der Tracker der Coach und nicht zu vergessen der Pro grammierer Der Tracker berwacht den Verlauf des Projektes und berpr ft ob das Ziel mit den vorhande nen Ressourcen erreichbar ist Der Coach ist f r den gesamten XP Prozess verantwortlich und versucht die Teammitglieder bei der Befolgung des Prozesses zu unterst tzen Der Programmierer ist f r die ihm zu geteilten Programmiert tigkeiten und f r die Erstellung und Ausf hrung geeigneter Testf lle zust ndig 5 3 XP Praktiken Das wesentliche an XP ist aber nicht die Art des Prozesses sondern die eingesetzten Techniken Im Folgenden werden XP Praktiken vorgestellt Planungsspiel Das Planungsspiel ist der Ersatz f r das Pflichtenheft Im Planungsspiel wird der Funkti onsumfang der Software festgelegt und die Aufwand betrachtungen von den Entwicklern werden erfragt Die User Stories werden wie bereits erw hnt vom Kunden auf Karten aufgeschrieben und nach Wichtig keit klassifiziert Die Entwickler sch tzen den Auf wand Coding Standards Die Entwickler definieren Co ding Standards an die sich allen im Verlauf des Pro jektes halten m ssen Im Unterschied zu anderen Softwareentwicklungsprozesse werden diese Standards von den Entwicklern sel
362. szeit mit einbezieht sie also als integra len Bestandteil des Softwareentwicklungsprozesses be trachtet 123 159 4 1 1 Anforderungen Anforderungen des Kunden sollten unbedingt schriftlich festgehalten werden denn aufgrund dieser Aufzeichnungen kann man bereits die ben tigten Ressourcen und die ben tigte Zeit zur Er f llung des Kundenwunsches berechnen und den Zeit punkt des Projektbeginns und endes festlegen Diese Anforderungen werden in einem Projektplan festgehal ten und dienen als Nachweis ber erbrachte Leistungen sowohl f r den Kunden als auch das Unternehmen 1 Wenn man den Projektplan erstellt sollte auf jeden Fall ber cksichtigt werden dass man pro Woche h chstens f nf Arbeitstage und pro Tag h chstens 8 Arbeitsstunden einplant So bleibt f r eventuelle Son derf lle ungeplante Aktivit ten und oder ungenaue Sch tzungen gen gend Zeit um zu reagieren 3 4 1 2 Entwurf F r eine realistische Zeitplanung ist es wichtig schon vor der Implementierung abzusch tzen wie viel Code man programmieren kann Das geschieht in der Entwurfsphase 4 1 3 Implementierung Ein Softwareentwickler soll te in der Lage sein ungef hr 60 Zeilen kommentierten Code pro Tag zu schreiben vorausgesetzt ein aus f hrlicher Entwurf der Software besteht bereits und das Testen und die Fehlersuche sind eigene Aktivit ten Das sauber entworfene Programm sollte aus Modu len bestehen 3 4 1 4 Test Fehler
363. t Diplomstudium Informatik Abstract Die DIN EN ISO 9000 ist eine Norm f r Ouali t tsmanagement und hat sich seit der Einf hrung in der Wirtschaft weit verbreitet In vielen Branchen ist eine Zertifizierung dieser Art bereits zu einem muss geworden Diese Arbeit behandelt die Entwicklung und den Aufbau der ISO 9000 Normfamilie wobei die Ver n derungen die diese Norm erlebt hat gezeigt werden Im Zuge dessen wird auf die grundlegenden Prinzipien der einzelnen Versionen eingegangen Die aktuell g l tige Norm ist die ISO 9000 Version 2000 die genauer betrachtet wird Zum Schluss wird die ISO 9000 Ver sion 2000 mit anderen Oualit tsmanagementsystemen verglichen und die Eignung in Bezug auf die Software entwicklung behandelt 1 Einleitung Die DIN EN ISO 9000 ff ist eine Normfamilie um Qualit tsmanagementsysteme international zu verein heitlichen Das Qualit tsmanagement kurz QM genannt soll sicherstellen dass G ter Dienstleistun gen Software und Prozesse den Anforderungen entsprechend hergestellt werden Die Hauptaufgaben sind eine umfassende Qualit tspolitik und die Ent wicklung von QM Zielen sowie die Verantwortungen f r die Planung Durchf hrung und Kontrolle dieser Ziele festzulegen Die Verantwortung dieser Aufgaben liegt bei der Unternehmensf hrung welche die Norm familie als wirkungsvolles Hilfsmittel zur st ndigen Qualit tsverbesserung einsetzen soll um den Anforde rungen am Markt gerecht z
364. t ist Um sowohl den Anforderungen der Bakkalaureatsarbeit schreibendenden als auch die Bed rf nisse und Kenntnisse der anderen unterschiedlichen Zielgruppen fair zu ber cksichtigen wird das Seminar als Konferenzseminar angeboten Dies bedeutet Ausgehend von einem f r alle Gruppen hoffentlich interessanten und jedenfalls bew ltigbaren Themenschwerpunkt Soft ware Qualit t siehe Aufforderung zur Beitragseinreichung bestimmen Sie ihr konkretes Seminar Thema werden Sie von der Seminarleitung gemeinsam mit den Kommilitonen betreut es liegt vielleicht etwas st rker als sonst blich in Ihrer Hand wie sich das Seminar entwickelt Konkret bedeutet dies folgendes Zeit und Arbeits Raster 2 M rz 04 Vorbesprechung und Gruppeneinteilung f r all jene die ein zweist ndiges Seminar besuchen wollen Bakkalaureanten und jene die sich die Lehrveranstaltung als 3 st ndiges Seminar anrechnen lassen wollen arbeiten als Einzelpersonen 9 M rz 04 Methodische Hinweise Besprechung von Einzelthemen der Referate 151 159 16 M rz 04 Fixierung der Einzelthemen Arbeitstitel der Referate 22 M rz 04 8 30 Uhr extended abstracts sind eingereicht Fallfrist 23 M rz 04 Hinweise zum Reviewing von Abstracts 30 M rz 04 Kurzpr sentationen Fragestunde 1 April 04 8 30 UhrReviews der extended abstracts f llig Fallfrist 7 April 04 Feedback zu extended abstracts bei Erst Autoren Osterferien Ausarbeitung der Langf
365. t mutation oder 2 Java auf die wichtigsten Merkmale objektorientierter die Testmenge konnte den Fehler nicht finden obwohl Sprachen eingegangen Dieser Abschnitt dient als der Mutant nicht quivalent ist killable non Grundlage f r die weitere Entwicklung der Arbeit da equivalent 2 Mutationsoperatoren auf Fehlern basieren die unter Ein Mutant ist funktional quivalent zum Original anderem durch Sprachmerkmale bedingt sind wenn er f r alle Inputmengen den gleichen Output erzeugt bzw es keinen Testfall gibt der ihn erkennen 3 1 Objektorientierte Sprachmerkmale Java kann Wenn ein Mutant nicht quivalent ist so existiert eine Testmenge T welche den Fehler F erkennt Somit gilt dass die bisherige Menge T ungen gend war Die Testmenge T muss solange gegenseitigen Abh ngigkeiten zwischen getrennt erweitert werden bis sie strong ist d h dem Tester geschriebenen Modulen durch strikte externe gen gt und F erkennt 3 Interfaces 5 Eine Aussage ber die Effektivit t der Testdaten erm glicht der Mutation Score Dieser Wert gibt Durch Kapselung ist es Objekten m glich den Aufschluss ber die Anzahl der erkannten Mutanten Zugriff auf ihre Variablen und Methoden durch andere Er ist definiert als die Anzahl der erkannten Objekte einzuschr nken In Java wurde dieses Konzept Mutanten Anzahl der nicht quivalenten Mutanten durch vier verschiedene Zugriffsmodifikatoren 100 Betr gt der Mut
366. t sich sowohl f r die Generierung von Applikationen als auch f r die Systemintegration und die Entwick lung von Infrastruktur siehe Zielgruppen BOEH00 PM A Gr e M bzw PM A Gr e M PM n M PERS RCPX RUSE PDIF PREX FCIL SCED PM ASLOC AT 100 ATPROD Abbildung 4 Formel Early Design Model Fir den Koeffizient A empfiehlt Barry Boehm in dieser Phase den Erfahrungswert 2 5 Dieser Wert ba siert auf der Auswertung der Datenmenge von zahlrei chen Projekten SOMMO1 Tabelle 2 Umrechnungstabelle FP in SLOC Erfahrungen u F higkeiten d sn sehr gering mittel hoch Entwicklers gerne hoch F higkeiten der sehr i F sehr CASE Werkzeuge gering germe mute hoch hoch PROD NOP Monat 4 iS 25 50 Sprache SLOC UFP Sprache SLOC UFP 4GLs 20 Lisp 64 Assembly 320 Pascal 91 C 128 Perl 27 C 55 Prolog 64 HTML 15 VB 5 0 29 Java 53 Visual 34 CH Da in dieser Phase durchaus bereits erstellte Komponenten wieder verwendet werden muss auch ein dementsprechender Reuse Anteil in Prozent reuse miteinbezogen werden Daher werden die Object Points OP um diesen Faktor gewichtet NOP Die Gr e wird in KSLOC kilo source lines of code also die Quellcodezeilen in Tausend angege ben Zur Erleichterung kann hier auch die Anzahl der Function Points in der Software gesch tzt werden und mit Hilfe von Standardtabellen in SLOC source
367. technik bestimmt insbesondere die Effizienz und Effektivit t der Inspektion d h wie viele Fehler werden in der Inspektion gefunden und mit welchem Aufwand geschieht dies Welche dieser drei Lesetechniken eingesetzt werden soll h ngt ganz und gar vom zu inspizierenden Dokument ab Checklisten sind besonders gut bei gut bekannten Anwendungsdom nen oder bei hnlichen Inspektions Objekten anwendbar da bereits auf Erfahrungen zur ckgegriffen werden kann und eventuell schon existierende Checklisten wieder verwendet werden k nnen Die Szenario basierte Lesetechnik sollte dann eingesetzt werden wenn das zu untersuchende Artefakt verh ltnism ig gro komplex und un bersichtlich ist Die ad hoc Methode wird wie schon erw hnt heutzutage kaum mehr eingesetzt da sie im Vergleich zu den anderen Techniken relativ uneffizient ist Tabelle 1 berblick der Lesetechniken Lesetechnik Anwendungsbereich Vorteile Nachteile Traditionelle Methode Wenig kompelx viel fehlende Struktur pro 7 7 Literatur und Er blematisch bei jedem Checklisten basiert Ar Fehlersuche derzeit kenntnisse verf gbar im Projekt auf neuem Gebiet met ae oie allgemeinen besser als mu eine neue Checkliste praxis in Unternehmen ad hoc erstellt werden Szenario basiert Wird heute in gro en Gute Fehlerabdeckung Teilweise komplizierter Unternehmen und durch unterschiedliche fin Vorbereitung und Projekten verwendet Perspektiven geringe Durchf
368. tel lung eines Projektplans Dieser Projektplan dokumen tiert die Prozeduren die Zeiteinteilung und das Ge samtziel des geplanten Projektes Definitionsphase Diese Phase beinhaltet all jene Aktivit ten die zur formellen Definierung eines Messprogramms notwen dig sind Als Ergebnis werden mehrere Dokumente erstellt 6 e der GQM Plan e der Messplan e der Analyseplan 107 159 Das Definieren von Zielen ist kritisch f r die er folgreiche Anwendung des GQM Ansatzes und wird von spezifischen methodischen Schritten unterst tzt Wie aus Abbildung 3 ersichtlich besteht ein Ziel GOAL aus mehreren Koordinaten Qualit tsaspekt Sichtweisen Ka NS os Abbildung 3 Koordinaten eines Goals 1 Es zeigt sich also dass ein Goal aus drei Koordi naten bestimmt wird Qualit tsaspekt Objekt Sicht weise Die erste dieser Koordinaten leitet sich aus der Un ternehmenspolitik her Durch die Politik und Strategie eines Unternehmens aber auch durch das Interviewen von relevanten Mitarbeitern lassen sich der Qualit ts aspekt und die Absicht eines Goals definieren Als zweite Informationsquelle dienen die Beschrei bungen und das Wissen ber unsere Prozesse und Pro dukte Hieraus wird das Objekt unseres Goals so exakt wie m glich formal definiert Die Sichtweise l sst sich durch unser Wissen ber die Organisation bzw Struktur der Organisation hin sichtlich unterschiedlicher Intere
369. ten auch wirklich sinnvoll Da die St rken und Schw chen der Expertenbefra gung genau kontr r zu denen der algorithmischen Mo delle sind wird diese Methode oft zu deren Unterst t zung verwendet Die St rken liegen vor allem darin dass neue Techniken Architekturen Anwendungen und au erordentliche Einfl sse ber cksichtigt werden k nnen Der Nachteil dieser Methode liegt in der Sub jektivit t Die Sch tzung ist nur so gut wie der Exper te wobei hier nat rlich immer eine pers nliche Note miteinflie t 1 2 3 Analogiemethode Diese Methoden versuchen einen Bezug zwischen vergangenen Entwicklungen und der geplanten Entwicklung herzustellen Man be dient sich hier Erfahrungsdaten aus ein oder mehreren abgeschlossenen Projekten unter der Verwendung von Vergleichskriterien Die Analogiemethode kann ent weder auf das ganze Projekt oder auf Teile dessen an gewendet werden Sie hat vor allem den Vorteil dass sie auch schon in den Fr hphasen eines Projektes ein gesetzt werden kann und sich an aktuellen und tats ch lichen Erfahrungswerten orientiert Andererseits ent steht nat rlich das Problem dass nicht genau gekl rt werden kann inwiefern die Einflussfaktoren von fr heren Projekten sich auch tats chlich auf ein aktuelles auswirken 1 2 4 Parkinsons Gesetz Laut dem Gesetz von Par kinson nimmt die Dauer einer Arbeit immer den Zeit raum an der ihr zur Verf gung steht Man geht also von einem festen Zeitrahmen
370. ten diese getestet werden 3 Ab welchem Test Abdeckungsgrad ist gen gend getestet worden 4 Wie k nnen bereits vorhandene Testf lle f r den Regressions Test wiederverwendet werden Durch die Abbildung der Klassenabh ngiskeiten in einem ORD kann man leicht herausfinden welche Klassen von einer nderung betroffen sind In diesem Zusammenhang wurde von Kung et al das Konzept der Class Firewall CFW vorgestellt CFW X die Class Firewall der Klasse X ist wie folgt definiert CFW K Xil X K E E ist die transitive H lle aller Kanten E des ORDs Wenn die Kante X X2 und X2 X3 in E enthalten sind so ist neben diesen beiden Kanten auch die Kante X X3 in E enthalten CFW K enth lt also alle von K transitiv abh ngigen Klassen Beispiel Die Klasse G aus Abbildung 7 wurde ge ndert und es soll ein Regressionstest gemacht werden Die Class Firewall von G lautet CFW G 1 J Nur die Klassen J sind transitiv von G abh ngig und m ssen erneut getestet werden Falls Z und J zyklisch abh ngig w ren m sste ein Algorithmus zum Aufl sen des Zyklus angewandt werden um eine Testreihenfolge zu finden siehe Abschnitt 4 1 So ergibt sich die Reihenfolge G vor und J 5 Zusammenfassung In dieser Arbeit wurde die N tzlichkeit von ORDs f r den Testprozess speziell f r Integrations und Regressions Testen gezeigt Die Verwendung von ORDs zur Ermittlung einer Testreihenfolge kann im Vergleich zu e
371. terschiedlichen Vor kenntnisse und unterschiedlichen Lehrziele eine untrag bare Situation ergeben h tte wurde f r die Betriebswirt schaftsstudierenden ad hoc ein eigenes von dieser Veran staltung getrenntes Seminar angeboten Die verbliebenen Studierenden hatten zwar weiterhin unterschiedliche Ein stiegsvoraussetzungen doch immerhin ein im Wesent lichen gemeinsames Ausbildungsziel Den Diplomstudie renden wurde angeboten in Spezialseminare aus den ge bundenen Wahlf chern zu wechseln Doch von dieser Option machten nur wenige Gebrauch sodass die Veran staltung letztlich mit 38 Studierenden 18 B 20 S den Lehrbetrieb aufnahm Das Rahmenthema Software Qualit t wurde bereits fr hzeitig bestimmt Ebenso wurde die Abhaltung als Konferenzseminar schon innerhalb der Sommerferien festgelegt als sich abzeichnete dass das Seminar mit einer Mischpopulation von Studierenden abzuhalten ist Im Gegensatz zu den bisher als Konferenzseminar abgehaltenen Spezialseminaren aus Software Enginee ring bei denen au er der Vorbesprechung der extra muralen geblockten Pr senzphase und einer unmittelbar davor stattfindenden Organisationsbesprechung die ge samte Betreuung der Teilnehmer ber e mail BSCW und im WS 2003 04 auch ber ein Konferenzmanagement system abgewickelt wurden wurden hier im wesentlichen w chentliche Pr senztermine vorgesehen Der Grund f r die unterschiedliche Durchf hrungsart lag einerseits in der hohen T
372. tieferen Klassen h her 3 3 Number of Children NOC DEFINITION 3 Die Metrik gibt die Anzahl der unmittel baren Subklassen der Klasse im Vererbungsbaum an Die Auswirkungen einer Klasse mit vielen Subklassen auf das Gesamtsystem kann mit dieser Metrik abgeschatzt wer den da Vererbung auch eine Form von Reuse darstellt Gibt es viele Subklassen ist die Wahrscheinlichkeit hoch dass Superklassen ungenau designed wurden was einen m glichen Missbrauch von Subklassen darstellen kann Ebenfalls gibt die Anzahl der Subklassen an welchen Gesamteinfluss diese Klasse auf das System bildet Bei einer Modifikation einer Klasse mit hoher Subklassenanzahl wird dadurch die Not wendigkeit des Testens anderer Komponenten essentiell 3 4 Coupling between Object Classes CBO DEFINTTION 4 Die Metrik gibt die Anzahl der Klassen an mit denen eine Klasse in einer Kopplungsbeziehung steht berm ige Kopplung zwischen Klassen steht im Gegen satz zu modularem Design und verhindert Reuse Je unab h ngiger eine Klasse ist desto einfacher ist es sie in anderen Systemen zu verwenden Um Modularit t und Kapselung zu verbessern sollte die Kopplung zwischen Klassen auf ein Minimum reduziert werden Ist die Kopplung zwischen Klassen zu gro ist die Anf lligkeit anderer Klassen auf nderungen im Design ebenfalls hoch und erschwert das Warten Eine Kopplungsmetrik ist somit n tzlich um zu bestimmen wie komplex der Testprozess f r das Design
373. tierte Softwareentwicklung vor allem durch die Anwendung neuer Strukturierungsmerkmale gegen ber der prozeduralen Softwareentwicklung aus Solch Strukturierungsmerkmale sind etwa Kapselung Abstrak tion Klassenhierarchie Vererbung Polymorphie und der Austausch von Nachrichten Ein weiterer wichtiger Unter scheidungspunkt ist der Einsatz von umfangreichen Klassen bibliotheken die den Reuse von Software unterst tzen sollen Aufgrund dieser Besonderheiten der Struktur von objektori entierter Software konnten viele der traditionellen Metriken nicht mehr angewendet werden Dies vor allem wegen der Unf higkeit der Metriken Konzepte wie Vererbung Poly morphismus und Nachrichtenaustausch zu erfassen und zu bewerten Dar ber hinaus konnten Softwaremetriken aus anderen Programmierparadigmen wie zum Beispiel die An zahl der Programmzeilen oder die L nge des Programms die Komplexit t von objektorientierter Software nur unzu reichend beurteilen F r weitere Beschreibungen der Eigen schaften von objektorientierten Softwaremetriken siehe 18 3 DIEMETRIKEN VON CHIDAMBER UND KEMERER 1994 definierten Shyam Chidamber und Chris Kemerer in 5 eine gro e Menge von objektorientierten Softwaremetriken wobei mittels sechs Kennzahlen die Qualit t eines objekt orientierten Systems beschrieben wird Innerhalb der Welt objektorientierter Softwaremetriken geh ren die Metriken von Chidamber und Kemerer zu den Meistreferenzierten Im folgenden w
374. tifizierung gewinnt man das Vertrauen der Kunden und Lieferanten Reduziert das Produkthaftungsrisiko Die Gesetzge bung besagt dass der Hersteller seine Unschuld am Produktfehler beweisen muss Ein Zertifikat ber ein vorhandenes QM Systems und eine genaue Pro duktdokumentation k nnte die Einhaltung der Sorgfaltspflicht belegen Die Auftragsbeschaffung wird erleichtert da viele Auftraggeber eine anerkannte Zertifizierung eines QM Systems fordern Optimierung der Arbeitsabl ufe Durch die Vorbe reitung auf die Zertifizierung werden Arbeitsabl ufe im Unternehmen genau analysiert und k nnen im Zuge dessen optimiert werden Die Zertifizierung fordert die Definition von wichti gen Dokumenten und die Regelung von Zust ndigkeiten und Befugnissen Dadurch wird das Qualit tsbewusstsein der Mitarbeiter und der Ge sch ftsf hrer erh ht Die Einf hrung eines QM Systems in ein Unter nehmen ist sehr wichtig und aufgrund der oben 96 159 genannten Argumente macht es auch Sinn dieses zertifizieren zu lassen Warum die ISO 9000 ff eine attraktive Variante ist wollen wir im Weiteren behan deln 2 Geschichte der Normfamilie ISO 9000 Um eine Grundlage f r die Geschichte der ISO 9000 Normfamilie zu schaffen wird der Begriff Norm erkl rt und die Gremien die f r diese Normen verant wortlich sind vorgestellt 2 1 Norm Der Begriff Norm laut DIN 820 Teil 1 Normung ist die planm ige durch die inte ressierten
375. tionen 4 3 4 Akzeptanzbeschreibung Ziele f r das gesamte Projekt Zusammenfassung der Akzeptanzkriterien haupts chliche Akzeptanzaktivit ten und Reviews Informationsbeschaffung Typen von Akzeptanzbe schreibungen Verantwortlichkeiten f r die Akzep tanzbeschreibungen 4 3 5 Akzeptanztestreview Produkte f r die Akzep tanz Ziele f r jeden Review Akzeptanzkriterien Bezugsquelle f r Zusatzinformationen zum Produkt Akzeptanzanforderungen Test und Untersuchungs techniken und ben tigter automatischer Support 4 3 6 Endg ltiges Akzeptanztesten Testplan und Akzeptanzkriterien Testf lle und Prozeduren Test ergebnisse und Analysen Werkzeugakquisition und berpr fung Belegschaft 4 4 STEP 4 F hre den Akzeptanztestplan aus Das Ziel dieses Schrittes ist zu bestimmen ob die Akzeptanzkriterien von einem gelieferten Produkt ge troffen wurden Das kann durch Reviews erreicht werden die immer wieder Zwischenprodukte betrach ten Es kann aber auch das Testen des ausf hrbaren Softwaresystems beinhalten Die Entscheidung welche Technik verwendet wird h ngt davon ab wie kritisch und wie gro die Software ist genauso wie von den involvierten Ressourcen und der Zeitspanne in der das Produkt entwickelt werden soll Der Review ber die Ergebnisse des Akzeptanztests ist meistens der letzte Schritt im Software Akzeptanz prozess Ein Vergleich von Schl sselpunkten zwischen dem Akzeptanztestplan und den tats chli
376. tisch erg nzt Die von ihm angesprochenen Metriken k nnen einerseits unmittelbar als Qualit tsindikatoren eingesetzt werden anderer seits stellen sie Daten zur Sch tzung des zu erwartenden Testsaufwands zur Verf gung siehe auch Arbeit von Lassnig und Wernig Pichler im Seminarteil Freilich ist bei all diesen Sch tzungen insbesondere bei solchen die sich auf gro e und lang laufende Projekte beziehen zu beachten dass Anforderungen nichts Statisches sind Soft ware Entwicklung ist auch ein Prozess der Erkenntnisgewinnung Anwender lernen im Laufe des Prozesses mehr noch w hrend des Einsatzes des neuen Systems ihre Bedarfe besser zu strukturieren und damit auch besser zu artikulieren und Entwickler erkennen das manches sich nicht so entwickeln l sst wie urspr nglich vorgesehen Daher ist es f r die Qualit t und Effizienz des Gesamtprozesses wesentlich m glichst genau zu wissen welche Anforderung sich an welcher Stelle des Entwurfs bzw der Implementierung wieder findet aber auch welche Globalanforderung ein bestimmtes Anforderungsdetail begr ndet Kerstin J RGL geht in der Arbeit Management of Requirements Traceability Problems diesen Fragen nach spannt das Problemfeld auf und referiert ber Kosten Nutzen berlegungen die gerade in diesem Bereich zentral sind um zu vermeiden dass man ein Fass ohne Boden ffnet Der Kreis der Bakkalaureatsarbeiten schlie t sich mit der Arbeit von Werner S HS ber Spannungen zwischen Benu
377. torientierten Konzepts soll durch folgende Mutationsoperatoren sichergestellt werden PNC new method call with child class type PNC ersetzt den durch den Aufruf von new zugewiesenen Typ einer Objektreferenz mit einem kompatiblen Typ Subklasse 6 Dadurch wird das Verhalten von kompatiblen Typen aufgezeigt und unter Umst nden auch m gliche ungewollte Typverwendungen aufgedeckt 9 Zum Beispiel siehe Figure 3 wird eine Objektreferenz mit dem Subtyp B einer Klasse statt dem eigentlichen Supertyp A erzeugt Original Code PNC Mutant Aa Aa a new A A a new BO Figure 3 PNC 6 PMD Member variable declaration with parent class Im Gegensatz zu PNC andert PMD die Deklaration eines Typs zu dessen Elternklasse d h nach obigen Beispiel wiirde a als C deklariert werden C ist Elternklasse von A Um diesen Fehler zu erkennen muss die Testmenge ein ung ltiges Verhalten aufgrund dieses Typs erzeugen 6 PPD Parameter variable declaration with child class type PPD entspricht dem Mutationsoperator PMD PPD arbeitet jedoch auf Parameterreferenzen von Methoden Er ndert Parameterreferenzen auf m gliche Elternklassen 6 PRV Reference assignment with other comatible PRV ersetzt Objektreferenzzuweisungen durch kompatible Objekte 6 Er entspricht insoweit PNC ist aber m chtiger berladen berladen hat zur Folge dass der Programmierer genau wissen muss welche Methode er wann mit welchen Parametern
378. triken festgelegt werden welche in einem GQM Plan zusammengefasst werden Zudem f hrt man In terviews durch welche die Definition von Goals unterst tzen Nach der Erstellung des GQM Plans muss ausgehend von den identifizierten Metriken ein Messplan erstellt werden Schlu endlich hat noch die Simulation des Vorgehens zu erfolgen In der Daten sammlungsphase entstehen die Kosten durch die Ein schulungen des Projektteams welches die Mitarbeiter darstellt die an dem zu messenden Projekt arbeiten Daneben entstehen Kosten durch die tats chliche Sammlung Validierung Kodierung und Speicherung der Daten In der Interpretationsphase m ssen die ge sammelten Daten ausgewertet und f r die Pr sentation an die Zielgruppe vorbereitet werden Bei der Routine Anwendung des GQM Programms stellt sich folgende Kostenstruktur dar 6 e Sch tzungsweise 30 des Aufwandes wird f r die Definierung des Messprogramms auf gewendet w hrend 70 f r die tats chliche Durchf hrung verwendet werden e 70 des Aufwandes entfallen auf das GQM Team und nur 30 werden dem Projektteam zugerechnet e Der Aufwand des Projektteams f r die Daten sammlung betr gt weniger als 1 ihrer tat s chlichen Arbeitszeit Dagegen stellt sich bei der erstmaligen Anwendung eines GQM Programms folgende Kostenstruktur dar 6 109 159 e Der Gesamtaufwand f r ein erstmalig durch gef hrtes GQM Programm ist um ca 60 h her als bei der Routine Anwen
379. tscheidungen treffen zu k nnen m ssen Daten und Informationen gesammelt und analysiert werden 8 Lieferantenbeziehung zum gegenseitigen Vor teil Eine Organisation und ihre Lieferanten sind voneinander abh ngig Die Verbesserung der Bezie hungen zum beiderseitigen Vorteil steigert die Wertsch pfung beider Unternehmen 4 ISO 9000 im Vergleich 4 1 TOM Total Quality Management Unter TQM versteht man ein umfassendes Konzept in dem das zentrale Ziel die Qualit t aus der Sicht des Kunden ist Ein solches Konzept entsteht nicht von alleine alle Beteiligten m ssen aktiv mitarbeiten und es muss der TQM Ansatz gelebt werden Die wich tigsten Prinzipien sind die st ndige Verbesserung die Kundenorientierung das Kunden Lieferanten Verh ltnis und die Prozessorientierung Balz98 S 339 ff 4 1 1 TQM vs ISO 9000 Die ISO 9000 1994ff beinhalteten nur Teile der TQM Prinzipien In der neuen Version der ISO 9000 Normfamilie wurden einige wichtige Prinzipien von TQM ber cksichtigt und somit ein Schritt in Richtung TQM gegangen Unter diesen Aspekten sind vor allem die Kunden Mitarbeiter Prozessorientierung und die st ndige Qualit tsverbesserung zu nennen Die soziale Komponente wird jedoch auch weiterhin bei TQM st rker behandelt Dem gegen ber ist die ISO 9000 besser fassbar und leichter in ein Unternehmen einzu f hren da nicht die Unternehmenskultur ge ndert werden muss Balz98 S 353 ff 4 2 CMM Capabilit
380. tut f r Normung Wien 1994 101 159 Requirements Engineering in globalen Projekten Marion Kury 9960541 mkury edu uni klu ac at Abstract Die allgemeine Globalisierung macht auch vor Softwareprojekten keinen Halt Immer mehr Projekte werden von Projektteams bearbeitet die ber die ganze Welt verteilt sind Diese neue Gegebenheit hat Auswirkungen auf die gesamte Projektentwicklung betrifft aber besonders die Requirements Engineering Phase da dies die kommunikationsintensivste Phase des gesamten Projektes ist Diese Arbeit befasst sich mit den Herausforderungen mit denen sich die Requirements Engineering Phase in globalen Projekten konfrontiert sieht Die geographische Distanz f hrt zu verschiedenen Problemen die sonst nicht auftauchen und verst rkt aber andererseits auch Probleme die w hrend der Requirements Engineering Phase in jedem Projekt auftreten In dieser Arbeit werden die auftretenden Probleme beschrieben und L sungsans tze vorgestellt Da jedoch f r etliche Probleme noch kein L sungsansatz vorhanden ist wird weitere Forschung in dieser Richtung angeregt Eine auf die neuen Gegebenheiten abgestimmte Requirements Engineering Methode ist zu erarbeiten 1 Motivation Die allgemeine Globalisierung schreitet voran Viele Unternehmen haben ihre Abteilungen ber die ganze Welt verteilt Davon ist auch die Softwareindustrie nicht ausgenommen Softwarehersteller f hren Projekte durch bei denen verschiedene
381. tware Entwicklungsorganisationen die dem SEI ihre Daten bermitteln befinden sich auf Stufe 1 SPBs spielen auf Stufe 1 noch keine Rolle 2 Sich auf Stufe 1 befinden bedeutet nicht dass eine Organisation nicht in der Lage ist gute Software herzustellen Aber es bedeutet dass durch verpasste Deadlines und viele weitere Prozessunzul nglichkeiten die Kosten f r Hersteller und Kunden zu hoch werden k nnen Um zu dem n chsten Reifegrad zu gelangen ist es notwendig ein Projektmanagement eine Qualit tssicherung und ein Change Control Management einzuf hren e Projektmanagement Der Ablauf von Projekten muss detailliert geplant und eine genaue Zuteilung von Ressourcen zu den einzelnen Projektschritten vorgenommen werden F r die erfolgreiche Projektdurchf hrung ist eine Einbindung des Managements unerl sslich Projektpl ne m ssen vom Management reviewed und offiziell bewilligt werden e Die Qualit tssicherungsgruppe stellt sicher dass es zu keinen Abweichungen von definierten Richtlinien kommt Sie ist unmittelbar der obersten F hrungsebene untergeordnet und erstellt f r diese laufende Reviewberichte e Die Change Control befasst sich mit der Kontrolle und berwachung von nderungen die sich aus den einzelnen Prozessschritten ergeben nderungen entstehen in jeder Prozessphase Anforderungsanalyse Design Implementierung Test F r jede nderung muss festgehalten werden welche Auswirkungen sie auf and
382. tware Engineering Terminology 1990 Knight 1993 Knight J C and Myers E A An improved Inspection Technique in Communications of the ACM Martin Tsai 1990 Martin J Tsai W T N Fold Inspection A Requirements Analysis Technique in Communications of the ACM ONeil 1995 Don O Neill National Software Quality Experiment Result 1992 1999 Software Technology Conference Salt Lake City 1995 1996 2000 Integrata 2000 Integrata Training News 4 2000 SETE 2003 Elke Hochmiiller Roland Mittermeir Heinz Pozewaunig 2002 03 Software Entwurf Test und Entwicklungs prozess Institut f r Informatik Systeme Universit t Klagenfurt Thaller 2000 Thaller Georg Erwin Software Qualitat VDE Verlag 2000 Visek 2003 Visek 2003 Virtuelles Software Engineering Kompetenzzentrum http www visek de Wheeler 1996 Wheeler 1996 Software Inspection an Industry best Practice 28 159 Qualit tssicherung bei agiler Softwareentwicklung Mario Graschl 9760974 mgraschl edu uni klu ac at Abstract Die agile Softwareentwicklung ist eine neue Me thode innerhalb der Softwareentwicklung Agile Soft wareentwicklung verspricht eine Technik die sich leicht den ge nderten Kundenanforderungen w hrend eines Projektes anpasst Es stellt sich nun die Frage ob dies die Art wie Qualit tssicherung betrieben wird beeinflusst Dieses Papier gibt einen berblick ber die agile S
383. twareprozess zu beseitigen Eine besondere Abweichung ist ein vor bergehender Umstand der eine unerwartete Abweichung in der Prozessleistung hervorruft Dieser SPB verfolgt die folgenden Ziele e Die Praktiken des Prozessmanagements erfolgen nach einem zuvor erstellten Plan e Die Prozessleistung des projektdefinierten Softwareprozesses wird quantitativ gelenkt e Die Prozessf higkeit des Softwareprozesses der Organisation ist in ihrer Quantit t bekannt Software Qualit tsmanagement befasst sich mit der Produktqualit t Folgende Ziele sollen erreicht werden e Die Projektaktivit ten f r die Softwarequalit t werden geplant Dieser SPB ist Teil des Softwareproduktplans der durch das Integrierte Softwaremanagement SPB Stufe 3 vom projektdefinierten Softwareprozess abgeleitet wird e Messbare Ziele f r Softwareproduktqualit t die mit dem Plan erreicht werden sollen und deren Einstufung werden definiert e Der konkrete Fortschritt zum Erreichen der Qualit tsziele f r die Softwareprodukte wird quantifiziert und geleitet Diese Ziele sollen sich in zwei Ergebnissen f r die Organisation widerspiegeln Dem quantitativen Verst ndnis der Qualit t von Softwareprodukten und dem Erlangen einer h heren Produktqualit t 2 3 Zur Erreichung des n chsten Reifegrades wird ein System zur automatischen Erfassung von Prozessdaten eingef hrt Dadurch kann auf ein umfassenderes Datenmaterial zugegriffen werden das f r die Pr
384. twicklers Anhand dieser Tests werden die User Stories berpr ft und vom Kunden als erf llt angesehen Collective Code Ownership und Refactoring Diese Praktik bezeichnet dass der fertig gestellte Code nicht im Besitz des jeweiligen Entwicklerpaares son dern im Besitz des Teams ist Das hei t bei notwen diger berarbeitung Refactoring von Programmteilen soll dies unter Einhaltung der definierten Standards sofort und unmittelbar geschehen und kann von jedem Entwickler durchgef hrt werden Voraussetzung hierbei ist dass bereits bestandene Tests weiterhin zu 100 erf llbar sind 34 159 Continuous Integration Fertiggestellte Tasks werden fortlaufend in das Gesamtsystem integriert Integration steht also nicht wie bei dem traditionellen Ansatz am Ende der Entwicklung sondern ist ein fort schreitender Prozess Nat rlich m ssen nach der In tegration alle bereits definierten Tests wieder erf llt werden Diese fortlaufende Integration soll gew hr leisten dass dem Kunden jederzeit eine Gesamtsicht ber das Produkt gegeben werden kann 5 4 Qualit tssicherungsma nahmen bei XP Wie anhand der Praktiken von XP ersichtlich ist Qualit tssicherung in XP haupts chlich 20 durch die Verwendung von Unit und Funktionstests realisiert Des Weiteren ist die Praktik des Pair Programming ein wesentlicher Qualit tssicherungsfaktor Durch den Einsatz von Pair Programming bekommt XP Elemente von Reviewing da sich die Programmierp
385. tzergewohnheiten und neuer Bedienbarkeit Sie verbindet Evo lutionsaspekte von Software Systemen mit Akzeptanzfragen S hs geht es allerdings nicht um jene Aspekte der Akzeptanz die klassischer Weise in einem vorab fixierten formalen Akzeptanztest zu kl ren sind Ihm geht es um die Probleme die Benutzer mit der Einf hrung eines Neusystems im Wechselspiel zwischen Verlust des Gewohnten und Gewinn des Neuen zu bew ltigen haben Probleme die von qualit tsbewussten Entwicklern zu antizipieren und weitestgehend zu minimieren sind Die Gruppe der reinen Seminararbeiten beginnt mit Ausf hrungen ber den Software Entwicklungsprozess Gudrun EGGER eine Lehramts Studierende gibt in CMM Eine Ein f hrung einen berblick ber das Capability Maturity Model von SEI und zeigt dessen Ent wicklung zu CMMI w hrend Birgit ANTONITSCH und Hubert GRESSL in Entwicklung von ISO 9000 die Neustrukturierung der in gewisser weise dazu komplement ren ISO 9000 Normenserie beschreiben und auf allgemeine Zertifizierungs berlegungen eingehen Mit Prozessaspekten die in interkontinental verteilt durchgef hren Projekten zu beachten sind besch ftigt sich Marion KURY in Aspekte des Software Engineering in globalen Projekten An diese drei Arbeiten schlie t ein Block mit Arbeiten zu Metriken an Er wird durch Aus f hrungen zur Goal Ouestion Metric Methode von Michael JAKAB und Michael OFNER er ffnet Johannes WERNIG PICHLER und Mario LASSNIG pr sentieren
386. u erwarten sondern auch eine bessere Produktivit t der Projektteams Neben der Fehlerkorrektur kann in einer Formalen Inspektion auch berpr ft werden ob das Dokument sich an gewisse Standards und Normen wie zum Beispiel den IEEE Standard h lt Ein weiterer Nutzen von Inspektionen zeigt sich nachdem das Softwareprojekt abgeschlossen ist Mit dem Auslieferungstermin ist der Software Lebenszyklus bekanntlich nicht zu Ende denn in der Wartungsphase wird oft sogar noch mehr Aufwand in die Software investiert als f r die Ersterstellung n tig war Software die bei der Ersterstellung einem Review unterzogen wurde verursacht weit geringere Wartungskosten als Software bei der dies nicht geschah Die Wartungskosten k nnen durchaus um den Faktor 10 bis 30 niedriger ausfallen Dazu ein Beispiel aus England in der Firma ICI wurden Inspektionen eingef hrt und im Laufe der Zeit bei 400 Programmen angewandt Sp ter wurden die Inspektionen wieder eingestellt vermutlich weil man den Nutzen von Inspektionen nicht eingesehen hatte und Kosten senken wollte Ein Jahr danach wurden die Auswirkungen dieser Entscheidung untersucht und dabei festgestellt dass die 400 Programme bei denen Inspektionen durchgef hrt worden waren nur ein Zehntel der Wartungskosten verursacht hatten wie 26 159 400 vergleichbare Programme ohne Inspektionen Integrata 2000 Das hei t mit anderen Worten wenn der Zeithorizont der Betrachtung nur bis zum
387. u werden Weiters muss der gesamte betriebliche Ablauf dokumentiert werden Eine Zentrale Rolle dabei bernimmt das QM Handbuch QMH in dem die Zust ndigkeiten und Regeln nach denen die Gesch ftsprozesse ablaufen niedergeschrieben werden Unternehmen k nnen sich ihr QM System mit ei nem Zertifikat best tigen lassen Diese Zertifizierung erfolgt nach entsprechenden Normen z B der ISO 9000 ff und wird von unabh ngigen Zertifizierungs stellen durchgef hrt Dabei ist wichtig anzumerken dass ein Zertifikat eines Unternehmen nichts ber die G te des Produk tes der Dienstleistung oder der Software aussagt sondern zeigt dass die Unternehmensleistungen durch definierte und dokumentierte Prozesse erstellt worden sind Es ist m glich dass ein Produkt eines nicht zerti fizierten Unternehmens die gleiche oder sogar h here Qualit t als ein ordnungsgem zertifiziertes Unter nehmen aufweist Diese unzertifizierten Unternehmen werden ihre Leistungen ebenfalls ber beschreibbare und auch reproduzierbare Prozesse erstellen nur eben ohne Zertifikat Aber dass ein chaotisch funktionieren des Unternehmen Produkte mit hoher Qualit t herstellt geschieht eher selten Die Zahl der zertifizierten Unternehmen hat in den letzten Jahren stark zugenommen Im folgenden Ab satz m chten wir auf die Gr nde dieser Entwicklung eingehen 1 1 Vorteile einer Zertifizierung Die Zertifizierung ergibt folgende Vorteile Werbung Mit der Zer
388. uf Analysen und Reviews des Produktes sowie auf den Ergebnissen der Software Product Assurance Aktivit ten 5 Der K ufer muss das Software Akzeptanzprogramm sorgf ltig planen und managen um sicherzustellen dass ausrei chend Ressourcen f r die Akzeptanztestakti vit ten zur Verf gung stehen 6 Der K ufer muss detaillierte Planung f r die Akzeptanztests in der ersten Planung des Software Akzeptanzprogramms einschlie en 7 Software Akzeptanz ben tigt Ressourcen und Zustimmung des K ufers vom Start des Projekts an 8 Als ein interaktiver Prozess der speziell den Anwender involviert resultiert die Vervoll st ndigung des Abnahmetests in der geliefer ten Software die den Benutzern die Services bietet die sie ben tigen 5 Welche Probleme k nnen bei Akzep tanztests auftreten Wie in jedem anderen Bereich k nnen auch hier Schwierigkeiten auftreten Zum Beispiel k nnen Unklarheiten auftreten wenn der Kunde Auftraggeber der Software nicht gleich zeitig auch der sp tere Benutzer ist Auf dieses Prob lem wird in Abschnitt 6 4 noch einmal eingegangen Solche Unklarheiten k nnen nur dadurch verhindert werden dass nicht nur der Auftraggeber sondern auch der sp tere Anwender in die Anforderungsanalyse mit einbezogen wird Somit w ren wir wieder beim Thema XP siehe Kapitel 3 letzter Absatz Schwierigkeiten ergeben sich auch wenn die Ab nahmekriterien zu ungenau ausgew hlt wurden Hier bei stellt
389. uf die damit entwickelte Soft ware angewendet werden Somit war man gezwungen neue passende Metriken zu entwickeln welche die Besonderheiten der Objektorientierung ber cksichtigen In dieser Arbeit wer den die Grundlagen von objektorientierten Metriken vorge stellt und auf die Unterschiede zu prozeduralen Metriken eingegangen Weiters werden objekt orientierte Software metriken vorgestellt beginnend mit den Metriken welche von Chidamber und Kemerer entworfen wurden und die zu den meistreferenzierten Metriken auf diesem Gebiet geh ren Ab geschlossen wir die Arbeit durch das Aufzeigen zweier Pro blemstellungen der Grenzwertproblematik und dem Einfluss der Klassengr e auf die Validierung von Metriken 1 EINLEITUNG In der heutigen Gesch ftswelt sind Softwarefirmen aufgrund der starken Konkurrenz gezwungen verl ssliche Software in immer k rzeren Releasezyklen zu entwickeln Dies gilt vor allem f r Bereiche in denen h chst verl ssliche Software be n tigt wird wie zum Beispiel in der Telekommunikation oder der Luft und Raumfahrt Aufgrund der hohen An forderungen an die Software wird f r diese ein entsprechen des Qualit tsmanagement ben tigt mit dem Attribute wie Testbarkeit Zuverl ssigkeit Fehleranf lligkeit oder Wart barkeit messbar sind Da jedoch viele dieser Attribute erst sp t im Entwicklungsprozess direkt gemessen werden k n nen ist es wichtig Softwaremetriken zu haben die schon fr hzeitig als Indikatore
390. ultiplikativ Faktoren werden multipliziert analytisch mathematische Funktion die nicht linear oder multiplikativ ist tabellarisch Werte werden einer Tabelle entnommen oder zusammenge setzt Kombination aus den bereits genannten Verfah ren sein Im Vergleich zu den anderen Arten haben algo rithmische Methoden eine Reihe von Vorteilen Sie sind objektiv k nnen nicht durch Wunschvorstellun gen oder pers nliche Ansichten beeinflusst werden sind wiederholbar und effizient Andererseits haben sie auch einige Schw chen Sie basieren auf fr heren Pro jekten und dabei stellt sich nat rlich die Frage wie repr sentativ diese Projekte f r die Zukunft sind Au Berdem k nnen sie keine au erordentlichen Einfl sse ber cksichtigen und wie jedes andere Modell auch sind sie abh ngig von der Qualit t der Eingabedaten und der Bewertung der Einflussfaktoren Die zwei wohl bekanntesten Vertreter dieser Me thode sind COCOMO das in einem sp teren Kapitel noch behandelt wird und die Function Point Analyse von Allen Albrecht 1 2 2 Expertenbefragung Bei dieser Methode wer den ein oder mehrere Experten befragt Sie erstellen ihre Sch tzung aufgrund ihrer Erfahrung und ihres Wissens Man unterscheidet hier also prim r zwischen Einzel und Mehrfachbefragungen Bei der Einzelbe fragung legt ein einziger Experte allein die Sch tzwer te hinsichtlich Aufwand Dauer und Kosten fest Han delt es sich um einen erfahrenen Experten der
391. und den Weg in die Praxis ebnen wird 6 Glossar Kopplungseffekt Komplexe Fehler sind an einfache Fehler gekoppelt sodass Testdaten die alle einfachen Fehler in einem Programm entdecken auch die meisten komplexen Fehler finden 1 Mutant Fehlerhaftes Programm das mithilfe eines Mutationsoperators aus dem Originalprogramm erzeugt wurde 1 Mutationsoperator Eine Regel die auf ein Programm angewandt wird um einen Mutant zu erzeugen 1 selective Mutation Es werden nur Mutanten erzeugt die sich von anderen Mutanten wirklich unterscheiden 1 weak Mutation Es wird nicht die Ausgabe des Mutanten mit der des Originalprogramms zum Schluss verglichen sondern der interne Zustand der beiden sofort nach Ausf hrung des mutierten Bereichs im jeweiligen Programm 1 7 Referenzen 1 A J Offutt R H Untch Mutation 2000 Uniting the Orthogonal Symposium on Mutation 2000 Mutation Testing in the Twentieth and the Twenty First Centuries San Jose CA October 2000 pp 45 55 2 A J Offutt A Practical Tool System for Mutation Testing Help for the common Programmer 12th International Conference on Testing Computer Software Washington D C June 1995 pp 99 109 3 M Bybro A Mutation Testing Tool for Java Examensarbete 1 Datalogi Stockholm August 2003 4 J Offutt S D Lee An Empirical Evalutation of Weak Mutation In IEEE transactions of Software Engineering May 1994 20 5 pp 33
392. ung Schulung Designlenkung usw Grunds tzlich muss man aber sagen dass die Normfamilie bis auf eine Reihe definierter Mindestan forderungen einen weitgehenden Spielraum bei der Erstellung eines QM Systems zul sst 2 5 Nachteile der Version 1987 Innerhalb kurzer Zeit wurde die Normenreihe durch internationalen Handel und die Wirtschaft ak zeptiert und gewann an Bedeutung Jedoch tauchten auch schnell Kritikpunkte auf Es wurde z B bem n gelt dass e die Benutzerfreundlichkeit der Normen sich nur auf Hardware produzierende Industriebereiche erstreck te Anbieter von Software und Dienstleistungen hingegen hatten Probleme bei der Benutzung und Umsetzung e die Dokumentenanforderungen f r kleinere Unter nehmen nur schwer zu erf llen waren e sich die Struktur der Normenreihe zu sehr an techni schen Gro unternehmen orientierte und es somit an Allgemeing ltigkeit mangelte e die Verwendung der Begriffe Lieferant Eink u fer und Kunde sehr verwirrend war Grunds tzlich sollte man aber auch erw hnen dass es international blich ist eine Norm nach einem Zeit raum von f nf Jahren einem Review zu unterziehen und insofern war die Zeit reif f r eine Neuauflage Thal96 S 33 Deshalb beschloss das zust ndige TC die Normfa milie weiterzuentwickeln An die neue Version wurden zwei Forderungen gestellt 1 Vorhandene Unklarheiten beseitigen 2 Die Normfamilie zu vereinfachen 3 Neue Entwicklung
393. ung zu rechnen ist 4 2 JavaNCSS 16 Ein weiteres freies Programm zur Softwaremessung unter Java ist JavaNCSS Leider bietet es keine echten OO Metriken sondern ausschlie lich traditionelle Metriken Non Commenting Source Statements NCSS ist eine Variante eines Statement Counters der in diesem Programm implementiert ist Die Cyclomatic Complexity von McCabe wird auch angeboten Ansonsten werden nur ein paar einfache Z hlungen durchgef hrt Anzahl Packages Klassen Methoden etc Metriken k nnen global auf Klassen oder auf Methoden Ebene eingesetzt werden Nenneswert ist die Integration in die Java Build Tools Ant und Maven 19 die das automatische Berechnen der Metriken beim Compilieren erm glicht 4 3 JDepend 17 In JDepend kommt die OO Design Quality Metrik von Robert Martin zum Einsatz Bei 13GNU General Public License f r freie Open Source Software 63 159 der Umsetzung in ein Metrik Tool liegt es manchmal im Ermessen des Entwicklers wie er die Metrik an die Gegebenheiten einer konkreten Programmiersprache anpa t Die Sprache Java erm glicht die Definition von Interfaces Interfaces erlauben im Gegensatz zu normalen Klassen Mehrfachvererbung d rfen aber keinen Code beinhalten Bei der Implementierung in JDepend hat sich Mike Clark der Programmierer dieses Werkzeugs entschieden Interfaces auch einfach als abstrakte Klassen zu z hlen Mit JDepend ist sowohl die interaktive An
394. ungen Durch die kontinuierliche Entwicklung ihres Prozesses steigt die Organisation von Stufe 1 auf Stufe 2 von da auf Stufe 3 etc Es bedeutet weiterhin dass Softwareprojekte nicht nur Aktivit ten umfassen die das Entwickeln von Software enthalten Wenn der Kunde bei einem Produkt Zuverl ssigkeit und Wiederholbarkeit erwartet sollte man den gesamten Produktionsprozess betrachten ganz gleich ob es sich um die Entwicklung oder die Wartung von Software handelt 94 159 7 Literaturverzeichnis 1 Helmut Balzert Lehrbuch der Software Technik Software Management Software Qualit tssicherung Unternehmensmodellierung Akad Verlag Heidelberg u a 1998 2 Kenneth M Dymond CMM Handbuch Das Capability Maturity Model fiir Software Springer Verlag Berlin u a 2001 3 James D Herbsleb David Zubrow Dennis R Goldenson Will Hayes Mark Paulk Software Quality and the Capability Maturity Model Commun ACM 40 6 ACM Press 1997 pp 30 40 4 James D Herbsleb Dennis R Goldenson A systematic survey of CMM experience und results Proceedings of the 18 international conference on Software engineering IEEE Computer Society Berlin 1996 pp 323 330 5 Watts S Humphrey Managing the Software Process Addison Wesley Boston u a 1989 95 159 Entwicklung von ISO 9000 Birgit Antonitsch 0060646 Hubert Gressl 0060188 bantonit hgressl edu uni klu ac a
395. unsicherer Software Die Entwicklung der Elektronik nahm rasant zu doch die Qualit t konnte dabei oft nicht mitgesichert werden Die Automobilindustrie gilt im Bezug auf die Qualit tssicherung der Produktionsprozesse als Vorreiter f r andere Branchen doch im Bezug auf die Software muss hier noch einiges an Arbeit getan werden Um diesem Problem entgegen zu wirken einigte sich die Automobilbranche auf gemeinsame Programmierstandards wie MISRA 4 MISRA MISRA steht f r Motor Industry Software Reliability Association mit Sitz in Warwickshire UK Misra ist eine Vereinigung verschiedener Organisationen innerhalb des Automotive Sektors die sich seit 1994 im Rahmen der MIRA Motor Industry Research Association gebildet hat Sie ver ffentlicht Programmierrichtlinien mit dem Schwerpunkt auf C zur Best Practice Software Entwicklung und Anwendung f r die Automobilbranche Dem Misra Standard haben sich inzwischen zahlreiche Automobilhersteller und Zulieferer angeschlossen Die Misra Guidelines k nnen im Internet unter www misra org uk heruntergeladen werden 4 Vorteile durch dieses erweiterbare Richtma sind dass ein angesehener Industriestandard und vergleichbare Qualit tszust nde erreicht werden k nnen Dadurch k nnen auch die Verfahren zur Qualit tssicherung wie zum Beispiel das Test und Risikomanagement schnell aber trotzdem gr ndlich durchgef hrt werden Dementsprechend steht MISRA mit seinem Namen f r Standa
396. urch beeinflusst werden Es dient dazu die laufenden Dokumente immer auf dem neues ten Stand zu halten w hrend die Implementierung weiterl uft Zus tzlich k nnen Manager Testverfahren kennzeichnen die die nderungen wieder verifizieren sollen Dieses Wissen speichert Testressourcen und garantiert eine Einhaltung des Zeitplans 2 2 Das Wie des RT Benutzt werden Prozesse Techniken und Werkzeu ge um Verh ltnisse aufzubauen und beizubehalten und getrennte Eing nge und Ausg nge in den Entwick lungsphasen aufeinander zu beziehen Die unten abgebildete Graphik zeigt die Phasen der Entwicklungen und den Anfang und die schlie lich entstandenen Endprodukte die mit jedem verbunden sind System and quality test procedures System specification t System software test procedures Reverse rn u test trace Software design Software description integration high level test procedures requirements Software specification Forward test t analysis Softwore design g description i Softwore unit detailed test procedures r i Source code Saftware unit units test procedures Abb 1 Ablauf Wie RT passiert 2 3 4 Welche Informationen miissen notiert wer den Wie die Uberschrift schon verdeutlicht stellt sich die Frage welche Arten von Informationen miissen berhaupt notiert werden Requirements Pre Traceability wird hergestellt wenn der Anforderungs definitionsprozess selbst nac
397. urch vermehrte Internetprojekte aber auch durch die Dynamik des Marktes schnelllebiger geworden Daher ist es schwieriger alle Anforderungen in der Analyse phase zu erheben Dies bedeutet eine genauere Anfor derungsanalyse vermehrter Aufwand bei der Doku mentation sowie den verst rkten Einsatz von neuen Softwaretechniken die es erlauben nderungen leicht einzubauen 4 3 Agile vs traditionelle SE Vergleicht man nun den agilen Ansatz mit dem traditionellen Ansatz so scheint der agile Ansatz die Probleme des traditionellen Ansatzes zu l sen und auf die nderungen hinsichtlich der Kundenanforderung zu reagieren Ebenso ist durch den inkrementellen Entwicklungsprozess gew hrleistet dass Qualit ts sicherung besser in den Gesamtprozess integriert wer den kann Andere Unterschiede ergeben sich aber auch hinsichtlicht den beteiligten Personen 12 Der einzelne Entwickler hat durch den agilen Ansatz eine gute Kenntnis ber das gesamte Projekt im traditio nellen Ansatz hingegen nur ber seine zu l sende Aufgabe Die Kommunikation tr gt im agilen Ansatz dazu bei dass Entwickler unterschiedlicher Module sich miteinander austauschen In der traditionellen Softwareentwicklung geschieht dies nur durch die definierten Schnittstellen und ber die Dokumentation Dem Kunden kommt in der agilen Softwareent wicklung eine gr ere Bedeutung zu er ist sozusagen vom Gedanken bis zur Geburt in das Projekt einge bunden und teilt seine ge nd
398. ware Engineering J J Marciniak ed Vol 1 John Wiley amp Sons 1994 pp 528 532 2 A Birk R van Solingen and J J rvinen Business Im pact Benefit and Cost of Applying GQM in Industry An In Depth Long Term Investigation at Schlumberger RPS Proceedings of the 5 International Symposium on Software Metrics Metrics 98 Bethesda Maryland November 1998 3 Fenton N E and S L Pfleeger Software Metrics A Rigorous and Practical Approach Second Edition Interna tional Thomson Publishing Inc London u a 1996 4 A Fuggetta L Lavazza S Morasca S Cinti G Oldano and E Orazi Applying GQM in an Industrial Software Factory Transactions on Software Engineering and Meth odology Vol 7 No 4 ACM October 1998 pp 411 448 5 S L Pfleeger and C L McGowan Software Metrics in process maturity framework Journal of Systems and Soft ware 27 9 ELSEVIER 1990 pp 255 261 6 Solingen R v and E Berghout The Goal Question Metric Method a practical guide for quality improvement of software development McGraw Hill Pub lishing Company London 1999 111 159 Objektorientierte Softwaremetriken Johannes Wernig Pichler 9961408 jwernigp edu uni klu ac at ZUSAMMENFASSUNG Mit dem Aufkommen der objektorientierten Programmierung konnten viele der bis dahin entwickelten Metriken zwecks der Besonderheiten welche dieses neue Programmierparadigma mit sich brachte nicht mehr a
399. wenn es einen Kernsatz von ausreichend validierten Metriken geben w rde mit denen die wesentlichen Aspekte von objektori entierter Software verl sslich beurteilt werden k nnten Die Definition eines solchen Kernsatzes von Metriken sollte nach Meinung der Autoren in naher Zukunft ein wichtiges Ziel der Forschung auf diesem Gebiet sein 8 LITERATUR 1 V Basili L Briand W Melo A Validation of Object Oriented Design Metrics as Quality Inidcators IEEE Transactions on Software Engineering Volume 22 No 10 pp 751 761 Oct 1996 2 D Bellin M Tyagi M Tyler Object Oriented Metrics An Overview Web Publication 1999 URL http www cs ube ca local reading proceedings cascon94 papers bellin ps 3 S Benlarbi K El Emam N Goel S Rai Thresholds for Object Oriented Measures NRC ERB 1073 NRC Publication Number NRC 43652 March 2000 URL http t iti nrc cnre ge ca iit publications iti docs NRC 43652 pdf 3Die Analysen wurden nur f r die Variable Fehleranf lligkeit durchgef hrt und gelten somit nur f r diese und nicht f r an dere Variablen wie etwa Wartbarkeit und Wiederverwend barkeit Number of methods added by a subclass 15 5 Average numbers of parameters per method 15 4 L Briand J Wiist J Daly V Porter Exploring the Relationships between Design Measures and Software Quality in Object Oriented Systems Journal of Systems and Software Volume 51 Issue 3 pp 245 273 2000
400. werden sodass sie klar definierten Regeln entsprechen 3 Dabei resultieren die Werte oder Symbole aus der Anwendung von Software Met riken wobei eine Messung mehrere Metriken und eine Metrik mehrere Werte umfassen kann In der Literatur ist eine gro e Anzahl von Metriken und Kategorisierungen f r diese angef hrt Keine die ser Metriken f r sich richtet sich aber direkt auf die drei Hauptziele die durch Messung gest tzt werden sollen Diese w ren 3 e Verstehen Die verschiedenen Aspekte von Prozessen und Produkten verstehen und do kumentieren um ein besseres Verst ndnis des Ofner Michael 9960295 crashproof gmx at Verh ltnisses von Aktivit ten zu Entit ten zu bekommen e Kontrollieren Die Erreichung der festgeleg ten Ziele validieren um bei Abweichungen korrigierend eingreifen zu k nnen e Verbessern Durch die Analyse der Daten aus den Bereichen Verstehen bzw Kon trollieren Verbesserungsm glichkeiten iden tifizieren und anwenden Es zeigt sich dass es notwendig ist eine kontext spezifische Auswahl an Metriken zu treffen um die oben angef hrten Ziele abdecken zu k nnen Daneben zeigen viele Studien die sich mit der Anwendung von Metriken und Modellen im industriel len Umfeld befassen dass effektive Messungen e auf bestimmte Ziele fokussiert sein m ssen e auf alle Produkte Prozesse und Ressourcen angewendet werden m ssen als auch e mit den unternehmensspezifisc
401. werden m ssen Menschliche Reaktionszeit Das Erkennen einer gef hrlichen Situation Aufmerksamkeit Die Erfahrung des Fahrers Risikobereitschaft 107 10 o SIL e Umsetzungsf higkeit des Fahrers und Handhabung des Systems e Arbeitsbelastung des Fahrers besonders im Moment des auftretenden Fehlers e Allgemeine k rperliche und geistige Verfassung Wie in dem letzten Zitat erw hnt ist es also durch den MISRA Standard m glich geworden das Sicherheitslevel 3 nicht zu berschreiten und man kann somit gravierende Unf lle mit gro en Verlusten vermeiden Ein weiterer L sungsansatz der von MISRA geboten wird ist der Vorschlag zum Einsatz eines berwachers bzw eines Einsch tzers der als unbeteiligter Dritter die Rolle eines Beobachters einnehmen soll Dieser hat die Aufgabe den Kunden und seine Interessen zu vertreten das Projekt zu berwachen sowie Fehler und Risiken einzusch tzen Der Grundgedanke besteht darin eine gewisse Unabh ngigkeit zu erreichen die nicht nur durch eine andere externe Person sondern auch durch andere Abteilungen Sektionen oder Firmen erreicht werden soll An vorderster Stelle sollte jedoch die Zusammenarbeit der einzelnen Gruppen stehen um Probleme wie Betriebsblindheit vermeiden zu k nnen In den MISRA Richtlinien werden auch Empfehlungen f r den Gebrauch von on board diagnistics ausgesprochen die die Sicherheit des Fahrzeuges in bestimmten Situationen gew hrleisten
402. wird ebenfalls behandelt 1 Einleitung Der Mutationentest ist eine sehr leistungsf hige Testmethode um ad quate Testdaten generieren und bewerten zu k nnen In der Praxis wird diese Art des Unit Tests nur sp rlich eingesetzt da der Aufwand enorm gro und nur f r entsprechend sensible Bereiche wie Life Critical Systems tragbar ist 1971 wurde die Idee des auf Fehler basierenden Tests von Richard Lipton in seiner Arbeit Fault Diagnosis of Computer Programms ver ffentlicht Wegweisend f r den Mutationentest war die Publikation Hints on test data selection Help for the practicing programmer von DeMillo Lipton und Sayward Schon fr h wurde dieses Konzept in einem entsprechenden Werkzeug f r prozedurale Programmiersprachen umgesetzt Mothra Doch wie sieht es mit Tools f r objektorientierte Sprachen wie Java aus die immer mehr an Bedeutung gewinnen Bevor diese Frage beantwortet wird m chten wir kurz das Konzept des Mutationentest erl utern 2 Mutationentest Dieser Test pr ft ob die Testdaten zwischen dem urspr nglichen Programm und den davon abgewandelten Programmen oder Programmteilen die f r spezifische Fehlertypen stehen unterscheiden k nnen Dadurch wird die Effektivit t der Testdaten ermittelt aber auch die im Programm selbst vorkommenden Fehler aufgezeigt In der IEEE Standard Terminologie werden Fehler in Failures und Faults eingeteilt Failures beschreiben externe ung lti
403. wird im letzten Abschnitt genauer eingegangen Ziele der gro en Revision e Anwendbarkeit f r Unternehmen aller Branchen und Gr en e die Ubersichtlichkeit in der Normenfamilie soll erh ht und die Zahl der Normen reduziert werden e Vereinfachung und Vereinheitlichung der ver wendeten Begriffe in der Norm e Das starre Prinzip des Nachweises der 20 QM Elemente soll durch ein flexibles System abgel st werden Die im Betrieb real ablaufenden Prozesse sollen die Struktur vorgeben e Orientierung am Nutzen aller interessierten Par teien und Verst rkung der Kundenorientierung e Verbesserung der Kompatibilit t und Integrations f higkeit mit anderen Managementsystemen z B Umweltmanagementsystemen e Unterst tzung von Bewertungsverfahren zur Ei genbewertung Brau02 S 17 ff 3 ISO 9000 2000 3 1 Aufbau der Normfamilie Version 2000 Um die Normfamilie zu vereinfachen und dessen bersichtlichkeit zu erh hen wurde folgende neue Struktur festgelegt 1508402 vor nach ISO 9000 ISO 9001 ISO 9002 ISO 9003 eae Dee Er Abbildung 1 Struktur der Normfamilie Brau02 Bild 2 S 18 cocoon ISO 8402 Definition der Begriffe und ISO 9000 1 Leitfaden zur Auswahl und Anwendung wurde durch ISO 9000 ersetzt ISO 9000 1 Leitfaden fiir ISO 9001 9002 9003 wurde mit den Normen ISO 9001 9002 und 9003 ver einigt und mit ISO 9001 benannt Der Leitfaden ISO 9004 1 der sich mit den Ele menten ei
404. wird mit G getestet 136 159 Dabei werden genau 4 Stubs ben tigt F r dieses kleine Beispiel kann gezeigt werden dass dieses Resultat optimal ist 4 2 1 Integrations Abdeckungsanalyse Durch die Integrations Abdeckungsanalyse ist die Bewertung eines Testprozesses m glich Dabei wird evaluiert wieviele Klasseninteraktionen getestet wurden So k nnen konkrete Qualit tsanforderungen an einen Integrations Test gestellt werden da im Allgemeinen nicht alle Klasseninteraktionen getestet werden Ein m gliches Kriterium w re zumindest 80 aller Variablen und Methoden Aufruf Assoziationen zu testen Hierbei ist der bereits vorgestellte Ext ORD hilfreich da dieser f r jedes Statement welches eine Assoziationsbeziehung ausl st eine Kante enth lt 4 3 Regressions Testen Regressions Testen ist das erneute Testen eines Programms nachdem man nderungen vorgenommen hat Der Regressions Test soll aufzeigen ob das Programm nach der nderung noch den Anforderungen entspricht und keine neuen Fehler enstanden sind Nat rlich m ssen nur die Teile bzw Klassen erneut getestet werden die auch von der nderung betroffen sind 3 Beim Regressions Testen gibt es 4 grunds tzliche Probleme die teilweise mit ORDs gel st werden k nnen 1 Wie identifiziert man die Komponenten die von einer nderung betroffen sind 2 Welche Strategie sollte angewandt werden um die betroffenen Klassen zu testen bzw in welcher Reihenfolge soll
405. xis Software Qualit t durch F hrung und Verbesse rung von Software Prozessen Carl Hanser Verlag M nchen Wien 2001 14 Homepage der T V Informationstechnik GmbH URL http www tuvit de 15 Homepage der Software Quality Systems AG URL http www sqs de 16 Harry M Sneed Software Qualit tssicherung Verlags gesellschaft Rudolf M ller GmbH K ln 1988 17 Homepage ber Extreme Programming URL http www xprogramming com 18 159 Die Formale Inspektion eine spezielle Review Technik Ursula Dittrich 0060922 udittric edu uni klu ac at Abstract Hohe Entwicklungskosten mindere Produkt qualit t und Fehler im Code sind nur einige der Probleme die bei der Entwicklung eines Software Produktes auftreten k nnen Erfahrungsgem schleichen sich in jedem Projekt w hrend aller Phasen des Entwicklungsprozesses Fehler ein Diese k nnen zu erheblichen Aufw nden f r unproduktive Nachbearbeitungst tigkeiten f hren sofern sie nicht fr hzeitig erkannt und behoben werden Die Bandbreite reicht vom einfachen Korrigieren eines Tippfehlers ber Anpassungen im Design bis zur umfassenden Neukonzeption des Projekts Einen wichtigen Beitrag zur fr hzeitigen Fehlererkennung leisten auf Projektebene Reviews und Inspektionen Diese Ans tze k nnen im Gegensatz zum Testen schon eingesetzt werden sobald ein Zwischenprodukt existiert auch wenn dieses nicht lauff hig ist Doch sie erh hen nicht nur die So
406. y Maturity Model In diesem System werden f nf Qualit tsstufen des Software Entwicklungsprozesses unterschieden Diese Stufen bauen aufeinander auf und beschreiben einen bestimmten Reifegrad des Entwicklungsprozesses Die Reifegrade reichen von der erste Stufe die einem cha otischen nicht reproduzierbaren Entwicklungsprozess entspricht bis zur Stufe fiinf die auf einen optimier ten sich st ndig verbessernden Entwicklungsprozess hinweist Balz98 S 262 ff 4 2 1 CMM vs ISO 9000 Der CMM Ansatz konzentriert sich haupts chlich auf die Qualit ts und Produktivit tssteigerung des Software Entwicklungsprozesses hingegen kann ISO 9000 f r verschiedene Branchen verwendet werden ISO 9000 ist ein fester Industriestandard CMM ist ein Hilfsmittel zur Problemanalyse und Prozessver besserung ist Beide Ans tze enthalten unabh ngige Audits um fangreiche Dokumentation und schlie en mit einem Zertifikat ab Es existieren kaum Erfahrungswerte von hoch ein gestuften Unternehmen in CMM im Gegensatz zur weit verbreiteten ISO 9000 100 159 Daraus ergibt sich dass man sich nicht zwischen ISO 9000 und CMM entscheiden muss sondern dass CMM im Bereich der Softwareentwicklung eine Er g nzung darstellt F r kleine und mittlere Software Unternehmen wird jedoch die Einf hrung von ISO 9000 aufgrund des Umfanges und den Anforderun gen einfacher sein Balz98 S 373 ff 5 Zusammenfassung In dieser Arbeit wurden grun
407. yse objektorientierten Source Codes Werner S HS Spannungen zwischen neuer Funktionalit t und Benutzergewohnheiten Programm der 3 Bakkalaureatsvortr ge 29 Juni 2004 SR 2 42 Brigitte GAUSTER Einsatz und Qualit tssicherung von life critical Software in der Automobilindustrie Ursula DITTRICH Die formale Inspektion Eine spezielle Review Technik Roland MITTERMEIR Abschlussbesprechung Ich ersuche die Vortragszeit von 25 bis 30 min einzuhalten Die Folien sollten bis Montag vor dem Vortrag jeweils Mittag in CLAROLINE abgelegt worden sein 159 159
408. ystementwurf durch den Systemtest getestet wird Genauer gesagt untersucht der Systemtest Eigenschaf ten und Verhalten das nur durch Testen des ganzen Systems feststellbar ist wie zB Performance Sicherheit oder Zuverl ssigkeit Abnahmetests unterscheiden sich von den anderen Testarten darin dass sie nicht versuchen Fehler zu finden sondern im Gegenteil nachweisen wollen dass alle Anforderungen erf llt werden Die Testf lle des Akzeptanztests sind meistens so aufgebaut dass sie die 9 159 Erf llung eines einzelnen Abnahmekriteriums belegen 3 Ein Beispiel f r einen Akzeptanztest w re Das System kennt die Kundennummern 100 200 und 300 Bei Eingabe einer dieser Nummern wird die Bestellung ins System bernommen Bei Eingabe einer anderen Nummer wird die Bildschirmseite f r die Neuerfas sung eines Kunden angezeigt Zum Abnahmetest geh rt auch die Vollst ndigkeit wurden alle Funktionen der Anforderungsdefinition realisiert und die Usability sind Fehlerausgaben angemessen wurden Ausgaben aufbereitet Format Stil Abk rzungen gibt es gen gend Redundanz in der Eingabe Optionen die nicht benutzt werden ist die Benutzerschnittstelle einheitlich 2 Wof r ben tigt man Abnahmetests Wie schon erw hnt ist der Akzeptanztest ein Indi kator daf r ob ein Programm seinen Anforderungen entspricht oder nicht Solange der Akzeptanztest nicht bestanden wird ist das System noch nicht fertig und der Entwick
409. zeigen 3 Des Weiteren sollte verhindert werden dass ein vertraglich vereinbarter Akzeptanztest zu einem Pr f stein f r die Praxistauglichkeit der Software um funktioniert wird Denn daf r gibt es den System und Installationstest 12 Ein anderer nicht zu vergessender Aspekt ist Was nicht im Anforderungskatalog explizit formuliert ist ist auch nicht Gegenstand eines vertraglichen Abnah metests 3 Was uns wiederum auf den Punkt der ge nau zu formulierenden Akzeptanzbedingungen f hrt Auch sollte man nicht die Zielsetzungen des Ab nahmetestens Testen des operationalen Betriebs des Systems au er Acht lassen 13 und au erdem sollte daf r gesorgt werden dass sich die Endbenutzer bei Test wirklich an die geplanten Testf lle halten denn durch eine nur willk rliche Benutzung des Systems k nnen Fehler bersehen werden 13 Eine problematische Situation entsteht auch wenn der Kunde zwei Wochen vor Durchf hrung der Akzeptanztests pl tzlich seine Anforderungen ndert Denn dadurch kann das Budget bez glich Zeit bzw 14 159 Geld stark in die H he schie en Verhindern kann man solche Situationen nur wenn der Kunde in die Anfor derungsanalyse miteinbezogen wird 4 6 Akzeptanztests in der Praxis Es gibt sogar Unternehmen zu deren Dienstleistun gen unter anderem projektbegleitende Qualit tssiche rung und Vorbereitungen zum Abnahmetest geh ren Solche Unternehmen sind die beiden deutschen Dienstl
410. zer auch nur unangemessen auf Ereignisse reagieren und wird Fehler begehen Ein normaler Autofahrer hat ein Gedankenmodell von seinem Auto er versucht die Zusammenh nge zwischen Lenkrad Motor Getriebe Batterie Reifen und allen anderen Komponenten zu verstehen L sst sich der Wagen einmal nicht starten w rden die meisten Fahrer annehmen dass die Batterie leer ist Tritt nun ein komplizierter Fehler auf muss der Wagen zu einem Mechaniker gebracht werden der ein unfangreicheres und korrekteres Gedankenmodell des Autos hat und so in der Lage ist es zu reparieren Benutzer eines neuen unbekannten Systems haben ein nur unklares Bild ber die Vorg nge und betrachten es anfangs als eine Art Black Box In ihrem geistigen Gep ck tragen sie Erwartungen und ltere Gedankenmodelle mit sich die zur Bildung eines fehlerhaften Modells f hren k nnen Fehler die nun begangen werden sind generell systematisch da ja nicht zuf llig vorgegangen wird sondern nach einem klaren System das eben nur fehlerhaft ist Eingesetzt werden Gedankenmodelle weil sie uns erlauben die Zukunft vorherzusehen wer das Licht seines Autos brennen l sst wei dass am n chsten Morgen die Batterie leer sein wird Au erdem helfen sie uns die Ursachen von beobachteten Ereignissen zu finden und sie sagen uns was zu tun ist um ein bestimmtes Ergebnis zu erzielen 7 Meistens wenn ein Benutzer einem neuen Programm gegen bersteht hat er bereits Erfahrung in
411. zesse messen zu k nnen wird von Gao 2 ein f nfstufiges Maturity Model vorgeschlagen Level 0 wird als Ad Hoc Komponententest beschrieben Ad Hoc Tests sind sehr ineffizient und durch die geringe Wiederverwendbar keit der Testinformationen Testtreiber und stubs auch sehr teuer Die Qualit t der Tests kann nicht kontrol liert und gesteuert werden Im Level 1 dem Standard Komponententest werden Standards definiert die die Informationsverarbeitung im Testprozess Testpl ne berichte Managementprozesse Configuration Management Qualit tkontrolle und Testkriterien beschreiben Level 2 entspricht dem gef hrten Kom ponententest Aktivit ten im Bereich der Messung bzw berwachung der Kosten der Qualit t und ver schiedener Testmetriken kommen hier hinzu Level 3 das zertifizierte Komponententesten ist dann erreicht wenn zertifizierte Standards definiert und implemen tiert wurden Dazu geh ren zertifizierte Testpl ne Testplattformen umgebungen metriken etc Und schlie lich ist Level 4 das systematische Komponen tentesten dann erreicht wenn systematische Methoden und Mechanismen definiert und implementiert sind die schlie lich zu einer Automatisierung der Testpro zesse f hren 2 4 3 Test Automatisierung Durch die Automatisierung von Prozessen ver spricht man sich einiges an Verbesserungen und Ein sparungen so auch beim Testen in der komponenten basierten Softwareentwicklung Wie dies
412. zifische dem Anwendungsgebiet angepasste Inhalte beziehen erstellt Die Inspektoren also die lesenden Teammitglieder untersuchen den Pr fling bez glich der vorgegebenen Kriterien der Liste Diese Kriterien die jeweils auf die Anwendungsdom ne und die konkrete Dokumentart abgestimmt werden m ssen werden als Richtwerte f r ein gutes Dokument herangezogen Dieser Fragenkatalog wird allen teilnehmenden Inspektoren ausgeh ndigt Die Inspektoren lesen das Dokument im Hinblick auf diese Punkte durch Ihre Aufgabe ist es diese Fragen vor w hrend und nach dem Lesen des Software dokumentes zu beantworten und entsprechend zu dokumentieren Die Pr fung des Artefakts ist beendet wenn alle Checklistenpunkte bearbeitet wurden keine Fehler mehr gefunden werden Wurde der vordefinierte Zeitrahmen erreicht bzw gesprengt dann wird die Pr fung zwar ebenfalls abgebrochen um die Gutachter nicht zu berfordern aber zu einem sp teren Zeitpunkt wieder aufgenommen Checklisten sind besonders gut bei gut bekannten Anwendungsdom nen oder bei hnlichen Inspektions Objekten anwendbar da bereits auf Erfahrungen 24 159 zur ckgegriffen werden kann und eventuell schon existierende Checklisten wieder verwendet werden k nnen Der grundlegende Vorteil der Checklisten basierten Lesetechnik besteht darin dass sie eine bessere Verteilung der Arbeit erm glicht Trotzdem ist sie wegen der allgemeinen Fragen und dem Mangel an konkreter Untersuchu
413. zten Maus entstand eine Oberfl che aus in der Gr e ver nderbaren Fenstern Buttons Popup Menus der Desktop Metapher einer objektorientierten Software Architektur und einer Entwicklungsbibliothek die seit den achtziger Jahren die Computerwelt dominiert Der Aufstieg von WIMP kam dann mit Steve Jobs und Bill Gates und der Macht der Firmen Apple Macintosh und Microsoft Von da an war es in der Computerwelt blich die verschiedensten Objekte direkt auf dem Bildschirm mit der Maus zu manipulieren Durch diesen bildlichen Einsatz von Metaphern ist das WIMP Interface intuitiv verst ndlich und heute jedem Benutzer vertraut Standards festgelegt von den Firmen Apple Macintosh und Microsoft definieren die Form der WIMP Interfaces und garantieren dass es f r die Benutzer keine berraschungen gibt 9 ETHICS steht f r effective technical and human implementation of computer systems und wurde von Enid Mumford in Manchester entwickelt und dient der Beteiligung der Benutzer am Softwareentwurf und der Entwicklung von Software die nicht nur effizient und effektiv ist sondern auch benutzerfreundlich und humanistisch Drei Grundziele werden durch Beteiligung der Benutzer am gesamten Entwicklungsprozess verfolgt Erlernen des Systems Akzeptanz der Software und Kontrolle ber die Ver nderung in der Organisation f r die die Benutzer arbeiten Hierf r werden folgende Schritte ben tigt Rechtfertigung der Ver nderung Abgrenzung d

Download Pdf Manuals

Related Search

Related Contents

  Sustainable Post Occupancy Transition: Herding CATS (Contractors    MANUAL DE UTILIZAÇÃO  LG DLE1310W Accessories Catalogue  Manuel d`utilisation de mon.vie  Vehicle Programming Instructions    KitchenAid 311 User's Manual  

Copyright © All rights reserved. Failed to retrieve file