Softwaredokumentation und Softwarewartung

Größe: px
Ab Seite anzeigen:

Download "Softwaredokumentation und Softwarewartung"

Transkript

1 Studienmaterial Verfahren und Systeme der Softwaredokumentation Softwaredokumentation und Softwarewartung MIP403 Prof. Dr. Dieter Friedrich

2 1 Verfahren und Systeme der Softwaredokumentation Softwaredokumentation und Softwarewartung Einleitung und Lernziele 4 1 Grundlagen und Begriffe Software Softwarewartung Softwarelebenszyklus Entstehungs- und Entwicklungsphase Evolutionsphase Erhaltungsphase Entsorgungsphase Softwareproduktmanagement Prototypmanagement Produktmanagement Projektmanagement Prozessmanagement 13 2 Arten, Aufwand und Risiken der Softwarewartung Softwareprodukttypen Wegwerfsysteme (specifyable-type) Statische Systeme (problem-solving-type) Dynamische Systeme (embedded-type) Alterung von Software Lack of movement Ignorant surgery Wachsende Entropie Legacy-Systeme Gesetze der Softwareevolution Wartungsarten und Wartungsprozesse Korrektive Wartung Präventive Wartung Adaptive Wartung Perfektionierende Wartung Reaktive und proaktive Wartung Aufwand für Wartung und Pflege Aufwandschätzung im Softwarelebenszyklus Fehlerarten und Wartungsaufwand Aufwandschätzung für Wartungsprozesse Aufwandschätzung für Wartung oder Systemablösung Risiken und Grundsätze der Wartung 28 Inhaltsverzeichnis

3 2 3 Organisation der Softwarewartung Aufbau einer Produktbetreuungsorganisation Prozessmanagement der Wartungsphase Organisation von Wartungsprozessen Organisation von Supportprozessen Rollen und Funktionen im Wartungsprozess Aufbau- und Prozessorganisation versus Projektorganisation Wartungsorganisation Supportorganisation Entwicklungsorganisation 44 4 Management der Softwarewartung Konfigurationsmanagement Aufgaben des Konfigurationsmanagements Elemente des Konfigurationsmanagements Änderungsmanagement Versions- und Release-Management Qualitätsmanagement in der Wartung Nutzungs- und Wartungsqualität Maßnahmen zur Qualitätssicherung 55 Copyright AKAD Bildungsgesellschaft mbh Ein Unternehmen der Cornelsen-Gruppe. Telefon: (07 11) Internet: Alle Rechte vorbehalten. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung der AKAD unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. 5 Softwaredokumentation Arten und Grundsätze der Dokumentation Arten der Dokumentation Grundsätze und Leitlinien der Dokumentation Codierrichtlinien und Style-Guides für Programmcode Zielsetzung, Inhalt und Adressaten der Dokumentation Ablage und Speicherung der Dokumentation Software-Artefakt-Management (SAM) Softwareprodukt-Repository 65 6 Testen in der Softwarewartung Grundlagen des Testens Modultests (Unit- bzw. Komponententests) Integrationstests (Interaktionstests) Systemtests Abnahmetests (Verfahrenstests, Akzeptanztests) Prüfverfahren und Testmethoden Statische Test- und Prüfverfahren Dynamische Testverfahren Testplanung in der Wartung 76 7 Metriken der Softwarewartung Arten und Zielsetzungen von Metriken Produktmetriken Volumenmetriken Struktur- und Komplexitätsmetriken Wartungsindex 84 Inhaltsverzeichnis

4 Metriken der objektorientierten Programmierung Prozessmetriken Metriken zur Messung der Zuverlässigkeit Metriken zur Aufwandsmessung 88 8 Werkzeuge zur Unterstützung der Softwarewartung Versionsverwaltungssysteme Testwerkzeuge Bug-Tracking-Systeme Aufgaben Nutzung und Beteiligte Beispiele für Open-Source-Bugtracker 95 Zusammenfassung 99 Antworten zu den Kontrollfragen 105 Abkürzungsverzeichnis 112 Literaturverzeichnis 114 Stichwortverzeichnis 117 Inhaltsverzeichnis

5 4 Einleitung und Lernziele Nach ihrer Einführung und Nutzung müssen sich Systeme unausweichlich verändern, wenn sie einsatzfähig bleiben sollen. Schon bald nach Inbetriebnahme einer Software ergeben sich neue Anforderungen und bestehende ändern sich. Geschäftliche Veränderungen ziehen oft neue Anforderungen an Bestandssoftware nach sich. Vielleicht müssen Teile der Software geändert werden, um während des Betriebs festgestellte Fehler zu korrigieren, sie an eine neue Plattform anzupassen oder ihre Leistung oder andere nicht funktionale Eigenschaften zu verbessern. Die Softwareentwicklung hört daher mit der Auslieferung eines Systems nicht auf, sondern setzt sich über die gesamte Lebensdauer des Systems fort. Die Erhaltung bestehender Software ist wichtig, da Organisationen inzwischen völlig von ihren Softwaresystemen abhängig sind und Millionen in diese Systeme investiert haben. Ihre Systeme gehören zum entscheidenden Betriebsvermögen, und sie müssen in Systemänderungen investieren, um den Wert dieses Betriebsvermögens zu erhalten. Der Hauptanteil des Softwarebudgets wird in großen Unternehmen daher für die Wartung bestehender Systeme eingesetzt. Zudem ist ein (erfolgreiches) Softwaresystem im größten Teil seiner Existenzdauer in Wartung. Softwarewartung hat also eine große Bedeutung. Wie Sie im Verlauf dieses Studienbriefs sehen werden, gehören zur Wartung im Vergleich zu den normalen Abläufen der Softwareentwicklung noch weitere Prozessaktivitäten, wie z. B. das Verstehen von Programmen. An dieser Stelle kommt die Dokumentation ins Spiel. Dokumente dienen zum Retten und Bewahren des Wissens über Programme, auf das schon während der Entwicklung zurückgegriffen werden kann. Besonders wertvoll sind die Dokumente jedoch für diejenigen, die die Software weiterentwickeln und warten müssen. Dies ist ein wesentliches Ziel der Dokumentation, und deshalb beschäftigen wir uns in diesem Modul nicht nur mit der Softwarewartung, sondern auch mit der Softwaredokumentation. Im ersten Teil behandeln wir die Grundlagen der Softwarewartung und geben Ihnen einen Überblick über die Grundlagen und die im Zusammenhang mit der Softwarewartung relevanten Begriffe. Sie erhalten eine Einführung in die Ursachen, Risiken und die verschiedenen Arten der Softwarewartung. Der zweite Teil beschäftigt sich mit der Organisation und den Managementthemen der Softwarewartung. Hier werden Wartungsprozesse beschrieben und es wird insbesondere das Konfigurations- und Qualitätsmanagement behandelt. Im dritten Teil folgt ein Kapitel, in dem Anforderungen und Probleme der Dokumentation erörtert werden. In weiteren Kapiteln werden Testverfahren und Metriken vorgestellt, die den Prozess der Softwarewartung unterstützen. Schließlich stellen wir im vierten Teil Werkzeuge zur Unterstützung der Softwarewartung vor. Am Beispiel von Trouble-Ticket-Systemen wird u. a. demonstriert, welche Anforderungen an eine Managementsoftware bestehen, die den Support-Prozess unterstützt. Einleitung/Lernziele

6 5 Nach Abschluss dieses Studienbriefs kennen Sie die wesentlichen Begriffe und Kategorien der Softwarewartung, können Sie erläutern, warum Softwarewartung wichtig im Produktlebenszyklus eines Softwaresystems ist, können Sie den Wartungsprozess und die Organisation der Softwarewartung skizzieren, kennen Sie die wesentlichen Elemente und Funktionen des Produkt- und Konfigurationsmanagements, können Sie erläutern, was eine gute Softwarewartungsdokumentation ausmacht, kennen Sie spezielle Aspekte und Techniken der Softwarewartung und wissen Sie, welche Funktionen Trouble-Ticket- und Bug-Tracking-Systeme beim Support und in der Wartung übernehmen. Über die Autoren dieses Studienbriefs Prof. Dr. DIETER FRIEDRICH unterrichtet als Dozent an den AKAD-Privathochschulen auf dem Gebiet der Wirtschaftsinformatik und lehrte am Institut für Wirtschaftsinformatik und Quantitative Methoden der TU Berlin. MATTHIAS KUPTZ ist Diplom-Informatiker. Er studierte Anwendungsorientierte Informatik (Ingenieursysteme) an der Universität Stuttgart. Er betreute bis 2008 für die AKAD-Hochschulen im Bereich Entwicklung und Produktdesign das Fachgebiet Wirtschaftsinformatik. Herr Kuptz verfügt über langjährige (z. T. internationale) Erfahrung im Informationsmanagement sowie in Softwareentwicklungs- und Standardsoftwareeinführungsprojekten in der Industrie wechselte er zur Daimler AG Stuttgart. Einleitung/Lernziele

7 6 1 Grundlagen und Begriffe Softwarewartung ist nach SOMMERVILLE 1 der Prozess der Softwareänderung nach der Auslieferung. Das klingt sehr abstrakt. Was ist Softwarewartung überhaupt? Ziehen wir einen Vergleich aus dem Betrieb von Eisenbahnen: Die Wartung von Gleisanlagen ist planbar; durch Berechnungen oder aus Erfahrung ist bekannt, dass die Gleise nach einer gewissen Zeit abgenutzt sind und sich ihre Eigenschaften (z. B. die Belastbarkeit) verändert haben. Sie werden deshalb periodisch geprüft und zum Teil ersetzt. Diese Wartungsarbeiten erfolgen aufgrund des Verschleißes der Gleise. Dagegen ist die Reparatur der Gleise nach einem Bahnunglück, etwa wenn eine Bahn entgleist ist, nicht planbar. Man kann zwar, da es Statistiken über solche Unfälle gibt, ein Budget für Reparaturen vorsehen, doch der einzelne, konkrete Unfall kommt immer überraschend. Die Arbeiten können nicht langfristig, bereits in der Entwicklung der Gleisanlagen geplant werden. Wir können also festhalten, dass Wartung im engeren Sinne (d. h. zur Kompensation der Abnutzung) präzise geplant werden kann. Dagegen werden Reparaturen überraschend notwendig und lassen sich nicht im Einzelnen planen. Da sich Software nicht abnutzt, gibt es für eine Wartung im engeren Sinne keinen Bedarf, wohl aber für Reparaturen und Änderungen. Natürlich sind Korrekturen notwendig, vor allem kurz nach der Auslieferung, wenn sich im Gebrauch Mängel zeigen. Aber die Korrektur ist nicht der einzige Grund für die Arbeiten an einer Software, die bereits im Einsatz ist. Eine Software, die intensiv genutzt wird, erzeugt neue Wünsche und Bedürfnisse. Je breiter der Einsatzbereich ist, desto größer ist die Zahl der Anforderungen, die sich ändern. Das bedeutet: Je erfolgreicher die Software ist, desto mehr Anpassungen und Erweiterungen braucht sie. Daraus erklärt sich der scheinbar paradoxe Zusammenhang zwischen Qualität und Wartungskosten: Je besser eine Software ist, desto höher sind ihre Wartungskosten, weil bessere Software länger und von mehr Menschen genutzt wird und darum häufiger neue Anforderungen auslöst. Sie sehen, Softwarewartung kann aus verschiedenen Gründen notwendig werden, z. B. um neue Funktionalität in die Software einzubauen, Fehler zu beheben, das Systemdesign zu verbessern oder den Ressourcenverbrauch zu senken. Insgesamt gibt es jedoch verschiedene Auffassungen darüber, was Softwarewartung ist, wie dieser Begriff abzugrenzen ist, wann sie beginnt und welche Teilaufgaben dazugehören. Unbestritten ist lediglich ihre große Bedeutung als längste und in vielen Fällen mit dem höchsten Aufwand verbundene Aktivität im Softwarelebenszyklus. 1.1 Software Der Begriff Software (SW) umfasst nicht nur die Programme, sondern auch die Verfahren, die zugehörige Dokumentation und die Daten, die bei der Entwicklung einer SW erzeugt werden und den Betrieb eines Computersystems unterstützen. 1 SOMMERVILLE, 2007, S Kapitel 1

8 7 Software besteht somit nicht nur aus dem Programmcode, zur Software gehören auch zahlreiche Dokumente, Unterlagen und Arbeitsmaterialien, die man manchmal auch als Artefakte bezeichnet. Zu den Artefakten zählen wir alle Produkte, die im Zusammenhang mit einer Systementwicklung erstellt werden, wie beispielsweise Anforderungsdefinitionen, Geschäftsprozessdarstellungen, Entwurfsdiagramme, Dokumentationen für Entwicklung, Benutzung, Betrieb und Wartung, Review-Berichte, Testumgebungen, Testdaten, Testprotokolle usw. P Bei der Beschreibung der Eigenschaften von Software wird in der Regel hervorgehoben: Software unterliegt keiner Abnutzung und keinem Verschleiß. Trotzdem unterliegt Software einem Alterungsprozess und muss gewartet werden. Software ist ein immaterielles technisches Produkt. Fehler sind daher nicht offensichtlich erkennbar. Selbst kleine Änderungen können massive Auswirkungen auf das Gesamtsystem und das Systemverhalten haben. Software gilt, im Gegensatz zu anderen (physischen) technischen Produkten, als leicht änderbar. Diese Änderbarkeit bezieht sich nur auf die formale Möglichkeit, den Quellcode der Software operativ einfach zu verändern. Unter dem Aspekt der Softwarewartung erfordert eine zielgerichtete (korrekte) Änderung von Software, mit der ein gewünschtes Ergebnis und nur dieses erreicht werden soll, in den meisten Fällen einen aufwendigen und komplizierten Eingriff in ein Softwaresystem. Die inhaltlich korrekte Änderung von Software ist daher in den meisten Fällen ein schwieriger Prozess. Schnelle, unbedachte, unsystematische Änderungen (quick fixes) einer funktionierenden Software können sich längerfristig als verhängnisvolle Fehler entpuppen. Zur Software gehören nicht nur der Programmcode, sondern auch zahlreiche Artefakte in Form von Dokumentationsunterlagen, Verfahren, Arbeitsunterlagen und Daten. Im Gegensatz zu anderen (physischen) Produkten hat Software besondere Eigenschaften: sie ist immateriell, unterliegt keiner Abnutzung und ist (formal) leicht änderbar, inhaltlich korrekte Änderungen sind hingegen meist schwierig. 1.2 Softwarewartung Der Begriff Softwarewartung wird häufig mit den Begriffen Fehlerbeseitigung und Softwarereparatur assoziiert. Der Begriff Softwarewartung hat jedoch mit dem geläufigen Begriff der technischen Wartung wenig gemeinsam. Aufgrund ihres immateriellen Charakters beinhaltet Software keine Verschleißteile und unterliegt somit keiner Form von Abnutzung. Im Unterschied zur technischen Wartung erfolgt bei der Softwarewartung nicht die Herstellung des ursprünglichen Zustands, sondern eine Veränderung der Software. Softwarewartung als Übersetzung des Begriffs software maintenance ist weiter zu fassen und sollte im Sinne von Softwareerhaltung, -instandhaltung oder -pflege interpretiert werden. Sie umfasst die Anpassung, Veränderung, Verbesserung, aber auch Reparatur von Software. BOMMER übernimmt bei der Klärung des Begriffs Softwarewartung die IEEE-Definition. Diese Definition der Wartung führt allerdings zu Widersprüchen: Auf der einen Seite gibt es bereits während der Entwicklung Probleme, die behoben werden müssen; Kapitel 1

9 8 diese Maßnahmen unterscheiden sich nur dadurch von der Wartung, wie sie in IEEE definiert wurde, dass das System noch nicht beim Kunden läuft. Auf der anderen Seite findet Softwareentwicklung oft inkrementell statt, und das System wird nach der Auslieferung planmäßig erweitert und ausgebaut. Das ist Entwicklung, keine Wartung. Offenbar spielt die Frage, ob es sich um geplante oder um ungeplante Arbeiten handelt, eine wichtige Rolle. Ludewig berücksichtigt in seiner Definition die Nichtvorhersehbarkeit der Softwarewartung 1 : Softwarewartung ist jede Arbeit an einem bestehenden Softwaresystem, die nicht von Beginn der Entwicklung an geplant war oder hätte geplant werden können und die unmittelbare Auswirkungen auf den Benutzer der Software hat. Diese Definition schließt Softwarereengineering aus, das die internen Eigenschaften, also die Wartungsqualität der Software, verbessert. Auch die Komposition bestehender Komponenten zu einem System wird nicht zur Wartung gezählt; die Komponenten sind ja für diesen Zweck entwickelt worden. Ludewig fasst Wartung und Reengineering unter dem Oberbegriff Softwarepflege zusammen. Unter dem Begriff Softwarewartung versteht man die nachträgliche Veränderung eines Softwareproduktes nach dessen Einführung (Auslieferung, Übergabe, Inbetriebnahme). Sie umfasst nicht nur die Softwarereparatur, die Änderungen der Software erfordert, um aufgetretene Fehler zu korrigieren. Im Rahmen der Wartung und Pflege einer Software können Änderungen auch durchgeführt werden, um die Performanz zu erhöhen, Artefakte zu verbessern oder die Software an veränderte Rahmenbedingungen anzupassen. Der englische Begriff software maintenance (Erhaltung, Instandhaltung) ist etwas weiter gefasst. Er umfasst alle Erhaltungsmaßnahmen, zu denen Korrektur, Reparatur, Support, Anpassung, Verbesserung und Weiterentwicklung von Software gehören. Er beschreibt die Anlässe zur Pflege und Veränderung von Softwareprodukten umfassender als der Begriff Softwarewartung, den wir aus Gründen der sprachlichen Vereinfachung im Folgenden weiter verwenden. Ferner sollte beachtet werden, dass der Begriff Softwarewartung in der Praxis in dreifachem Sinne verwendet wird. Er bezeichnet die Tätigkeit der Programmierer, die eine Änderung an einem Softwaresystem nach dessen Auslieferung vornehmen, als (Geschäfts-)Prozess die Schritte, die in einem Wartungsfall sequenziell durchgeführt werden, im Lebenszyklus die Phase der Veränderungen eines Softwaresystems nach dessen Erstellung bis zur Ablösung oder Stilllegung. Softwarewartung kann als Tätigkeit, als Geschäftsprozess oder als Phase des Softwarelebenszyklus aufgefasst werden. Der englische Begriff software maintenance beschreibt die Erhaltung und Instandhaltung nach der Auslieferung an den Kunden oder Benutzer. Manche Autoren nehmen den Support und die Weiterentwicklung der Software von der Wartung aus. 1 LUDEWIG, Kapitel 1

10 9 1.3 Softwarelebenszyklus Ausgangspunkt der Überlegungen zur Softwareentwicklung, Softwarewartung und Softwarenutzung ist der Softwarelebenszyklus. Problemstellung, (Vorbereitung, Projektstart) Anforderungsanalyse (Requirement Analysis) Spezifikation Entstehungsphase Abbildung 1: Hierbei unterscheidet man die Phasen: Lebenszyklus der Softwareentwicklung, Softwarewartung und Softwarenutzung Design Programmierung, Implementierung Test (Modul-, Integrations- Abnahmetest) Entwicklungsphase Einführung (Auslieferung, Übergabe, Installation) Betrieb Verbesserung, Erweiterung, Sanierung, Migration Evolutionsphase Maintenance (Wartung, Pflege) Erhaltungsphase Stilllegung, Entsorgung, Ablösung Entsorgungsphase Es wird der gesamte Lebenslauf eines Softwareprodukts von der Problemstellung und Initialisierung der Entwicklung bis zur Ablösung oder Stilllegung (EOL: end of life) dargestellt. Die linke Seite des Diagramms unterscheidet die verschiedenen Entwicklungsphasen, die Sie schon im Zusammenhang mit dem Wasserfallmodell kennengelernt haben. Die rechte Säule zeigt das 5-E-Modell des Softwarelebenszyklus, bei dem die folgenden fünf Phasen unterschieden werden: 1. Entstehung 2. Entwicklung 3. Evolution 4. Erhaltung 5. Entsorgung Kapitel 1

11 Entstehungs- und Entwicklungsphase Der Fokus des Softwareengineering richtet sich traditionell auf die Planung und die Neuentwicklung von Software, also auf die Entstehungs- und Entwicklungsphase des Lebenszyklus. Hierfür wurden zahlreiche Vorgehens- und Entwicklungsmodelle konzipiert. Hier begegnen uns neben dem klassischen Wasserfallmodell u. a. das Spiralmodell, das V- Modell, Prototyping, das iterative Modell (Jacobson), der Rational Unified Process (RUP von IBM) und die agile SW-Entwicklung als mögliche Vorgehensmodelle der Softwareentwicklung Evolutionsphase Nach der Übergabe (Freigabe) oder Auslieferung eines SW-Produkts beginnt die Phase des Betriebes, der Wartung und der Instandhaltung. Die Auslieferung bzw. Übergabe (Abnahme) eines Softwareprodukts stellt im Lebenszyklus eine Zäsur dar. Fehler, die nach diesem Zeitpunkt auftreten, müssen im Rahmen der Wartung behoben werden. Sie verursachen nicht nur hohe Wartungskosten, sie haben in der Regel auch erhebliche Konsequenzen für Haftungsansprüche und verursachen unter Umständen hohe Ausfallkosten. In dieser Phase entsteht Korrektur- und Änderungsbedarf, der je nach Softwarequalität erheblich sein kann. Der Korrektur- oder Änderungsbedarf nach Auslieferung führt dazu, dass die Phasen Spezifikation, Design, Implementierung und Test während der Betriebsphase wiederholt durchlaufen werden (müssen), sodass der Lebenslauf einer Software nicht als geradliniger Lebenslauf, sondern als Zyklus aufgefasst wird, so wie er durch das oben dargestellte Lebenszyklusmodell charakterisiert wird. Da eingebettete Systeme (definitionsgemäß) in eine Organisation eingebettet sind, erfordern diese Prozesse laufende, evtl. zeitraubende Rückkopplungen (feed-backs) der Kommunikation und der Konsultation, nicht nur zwischen verschiedenen Ebenen der Aufbauorganisation (z. B. Management, betroffene Anwender, Benutzer, SW-Entwickler, Personalvertretung), sondern evtl. auch mit Kunden und Lieferanten. Die Evolutionsphase bietet insbesondere zahlreiche Möglichkeiten, die Software zu perfektionieren und zu verbessern. Hierzu gehören nicht nur die Korrektur der Restfehler, die erst beim Betrieb entdeckt werden, sondern auch vielfältige Möglichkeiten des Software Reengineering. Unter dem Begriff SW-Reengineering werden zahlreiche Maßnahmen zusammengefasst, die in der Literatur ausführlich erörtert werden. Hierzu gehören u. a. die Restrukturierung, Refaktorierung (Refactoring), Bereinigung, Kapselung oder Konvertierung von Software. Bei der Refaktorierung wird das bestehende Design eines Softwaresystems verändert. Es werden keine zusätzlichen Funktionen hinzugefügt oder verändert, sondern es wird nur das interne Design des Softwarecodes verbessert. In diesem Zusammenhang sollte erwähnt werden, dass im Gegensatz zu der umfangreichen Literatur, die zum Thema Reengineering existiert, umfassende Reengineering Maßnahmen in der Praxis eher selten durchgeführt werden. Die wichtigsten Maßnahmen der Evolutionsphase sind Projekte zu laufenden Anpassungen, Korrekturen und Fortschreibungen des Fachkonzepts aufgrund veränderter wirtschaftlicher und technischer Rahmenbedingungen (vgl. E-Typ-Systeme im folgenden Kapitel 1

12 11 Kapitel). Ähnlich wie bei der Entwicklungsphase, werden auch hier die verschiedenen Entwicklungsschritte so wie am Prototyp des Wasserfallmodells dargestellt zyklisch durchlaufen. Wichtig ist in diesem Zusammenhang die Fortschreibung und Implementierung des weiterentwickelten Fachkonzepts, solange dies mit vertretbarem Aufwand möglich ist Erhaltungsphase In dieser Phase findet nur noch eine Instandhaltung mit geringen Nachbesserungen statt. Mit geringem Aufwand wird versucht, das System am Leben zu erhalten. Das setzt voraus, dass die technische Umgebung für den Betrieb unterstützt wird und Mitarbeiter zur Verfügung stehen, die bereit (und befähigt) sind, das alternde System zu pflegen. Anwender neigen dazu, nicht zuletzt auch aufgrund von Wirtschaftlichkeitsüberlegungen bei Reinvestitionsmaßnahmen, an technologisch und softwaretechnisch veralteten Systemen möglichst lange festzuhalten (vgl. Legacy-Systeme). Ferner macht es die Reengineering- Technik der Kapselung (wrapping) möglich, solche Systeme in einer modernen Softwareumgebung mit Web-Architektur weiter zu betreiben und zu nutzen. Damit kann man die Lebensdauer solcher Systeme nochmals verlängern. Der Betrieb von Legacy-Systemen sowie Reengineering-Aktivitäten tragen dazu bei, dass die Lebensdauer von Softwaresystemen, die bei Beginn der Systementwicklung nur schwer abschätzbar ist, häufig unterschätzt wird. Ist die tatsächliche Lebensdauer länger als geplant, hat dies zur Folge, dass auch der hierbei anfallende Aufwand für Wartung und Pflege, der das 3- bis 4-fache des ursprünglichen Entwicklungsaufwands betragen kann, in der Gesamtsumme höher ausfällt und daher ebenfalls unterschätzt wird Entsorgungsphase In den meisten Fällen trägt das Auftreten externer technischer, wirtschaftlicher oder organisatorischer Ereignisse (z. B. Wechsel der Systemumgebung, Beschaffung integrierter Softwaresysteme, Datumswende im Jahr 2000, EURO-Einführung usw.) dazu bei, eine veraltete Software herunterfahren, ablösen und entsorgen zu müssen. Auch in der Phase des EOL sind zahlreiche Aktivitäten erforderlich. Hierzu gehören die Kommunikation mit den Benutzern, die Datensicherung, die Deinstallation und die Dokumentation der Archivierung. In manchen Fällen muss das alte System während einer Übergangsphase im Hintergrund noch verfügbar oder reaktivierbar sein. Eine Reaktivierung kann beispielsweise zur Beweissicherung bei rechtlichen Auseinandersetzungen, sowie bei Aktivitäten der Innenrevision, der Wirtschaftsprüfung oder der finanzamtlichen Betriebsprüfung erforderlich sein. Zur Archivierung von alten Releases gehören der Quellcode, die Werkzeuge, das Betriebssystem, die Compiler, die Build-Skripte (zur Systemgenerierung des Maschinencodes), die Dokumentation und in Ausnahmefällen sogar Teile der Hardware. Der ISO/IEC Standard schlägt für die Abkündigung und die Außerbetriebnahme einer Software folgende Maßnahmen vor: Außerbetriebnahmeplan für Zeiträume des vollen oder teilweisen Supports, Archivierung der Software (inkl. Dokumentation), Kapitel 1

13 12 Verantwortung für künftige Supportanfragen, evtl. Übergang zu einem neuen System, Zugriffe auf die archivierte Software, Absichtserklärung, Abkündigung, Außerbetriebnahme der Software, Archivierung der Baseline. Die Betrachtung der Wartung unter dem Aspekt des Lebenszyklus einer Software macht den zyklischen Prozess der Entstehung, der Entwicklung, der Evolution, der Erhaltung und der Entsorgung deutlich, bei dem die Bedeutung der Evolution und der Erhaltung (d. h. der Maintenance bzw. der Wartung im weiteren Sinne) meist unterschätzt wird. 1.4 Softwareproduktmanagement Sinn und Zweck der Softwareentwicklung kann es nicht sein, laufend neue Anwendungssysteme zu entwickeln, bloß weil sich die technischen und wirtschaftlichen Rahmenbedingungen laufend ändern. In vielen Fällen ist es vernünftiger, die genutzten Systeme zu erhalten, zu pflegen und weiterzuentwickeln, so wie es im Modell des Softwarelebenszyklus beschrieben wird. Dies ändert auch die Anforderungen an das Softwaremanagement. Softwarewicklungsprojekte sind für einmalige, befristete und eindeutig abgrenzbare Vorhaben mit bekannter vorgegebener Zielsetzung konzipiert. Aus dem SW-Projektmanagement entwickelt sich im Verlauf der Softwareevolution eine Daueraufgabe. Das SW-Projektmanagement mutiert zum permanenten Lebenszyklusmanagement eines Softwareprodukts, dem sog. Softwareproduktmanagement. Das Produktmanagement muss während des Lebenszyklus auch das Management der laufenden Erhaltungsmaßnahmen, der Weiterentwicklung und der Weiterentwicklungsprojekte übernehmen. In dieser permanenten Rolle ist das Produktmanagement auch für das Management von SW-Folgeprojekten verantwortlich und fungiert als Projekt der Projekte. Zur Unterstützung der Lebenszyklen der Softwareevolution muss das Produktmanagement auch das Konfigurationsmanagement übernehmen, das im Folgenden noch ausführlicher erörtert wird. Bei der Entwicklung und Wartung kommerzieller, am Markt angebotener Anwendungssoftware wird dem Produktmanagement in der Regel auch die Verantwortung für den Vertrieb, das Marketing und die Kundenbetreuung übertragen. Software Produktmanagement ist ohne Softwareengineering nicht denkbar. Aufgrund der Vielzahl von Koordinationsaufgaben, Funktionen und Verantwortlichkeiten, die das Produktmanagement während der Lebensdauer einer Software übernehmen muss, ist ein umfassendes Softwareengineering erforderlich. SNEED bezeichnet dies als Softwareengineering im großen Stil (vgl. SNEED, H. M. et al. 2005, S. 7), dessen zentrale Rolle sich mit den vier P-Begriffen Kapitel 1

14 13 Prototyp, Produkt, Projekt, Prozess einprägsam charakterisieren lässt Prototypmanagement Das Prototypmanagement konzipiert, steuert und überwacht die Neuentwicklung (Erstentwicklung) von Softwareprodukten, die als SW-Prototypen aufgefasst werden können Produktmanagement Das Produktmanagement ist verantwortlich für das gesamte Softwareprodukt, das nicht nur aus Programmen besteht, sondern zu dem auch zahlreiche Artefakte wie Dokumente, Daten, Testfälle usw. gehören Projektmanagement Das Projektmanagement übernimmt die Verantwortung für alle während der Softwareevolution anfallenden Projekte. Es sind dies insbesondere folgende Projekttypen: Entwicklungsprojekte, Weiterentwicklungsprojekte, Systemerhaltungsprojekte Prozessmanagement Im Mittelpunk des Softwareengineering, des Software Reengineering und der Softwarewartung stehen nicht nur Projekte, sondern auch Routineabläufe, die als Geschäftsprozesse der Wartungsphase definiert werden können. Das Produktmanagement übernimmt hierbei die Verantwortung für das gesamte Prozessmanagement, also für die Gestaltung und das Controlling der Wartungsprozesse. Kapitel 1

15 14 Oft ist es wirtschaftlicher, nicht laufend neue Systeme zu entwickeln, sondern die vorhandene Software möglichst lange zu erhalten und zu pflegen. Der Aufwand für Evolution und Erhaltung erhält bei der Beachtung des Lebenszyklus eine größere wirtschaftliche Bedeutung. Die Methoden und das Management der Softwareentwicklung verlagern sich auf die methodische Unterstützung und das Management des gesamten Lebenszyklus und damit auf das sog. Produktmanagement. Die erweiterten Aufgaben des Produktmanagements, das auch das Management der Wartung umfasst, lassen sich mit den vier P-Begriffen charakterisieren: Management von Prototyp, Produkt, Projekt und Prozess. K [1] Wie unterscheidet sich Software von anderen, materiellen Produkten? K [2] Erläutern Sie im Zusammenhang mit der Softwareentwicklung und -wartung den Begriff Artefakt. K [3] Nennen Sie die fünf E-Begriffe, mit denen sich der Lebenszyklus von Softwaresystemen kurz charakterisieren lässt. K [4] Was versteht man unter der Refaktorierung (Refactoring) von Software? K [5] Beschreiben Sie den Unterschied zwischen den Aufgaben des Managements bei der Softwareentwicklung und beim Softwareproduktmanagement. K [6] Nennen Sie einige der notwendigen Maßnahmen, wenn Sie am Ende des Lebenszyklus (EOL) eine Software stilllegen und entsorgen wollen. K [7] Welchen Phasen des Softwarelebenszyklus lassen sich die Begriffe Softwareengineering und Software Reengineering am besten zuordnen? Kapitel 1

16 90 8 Werkzeuge zur Unterstützung der Softwarewartung Softwaresysteme, die den kompletten Wartungsprozess abdecken, sind rar und Gegenstand von Forschungsprojekten. Im Einsatz befinden sich vorwiegend Einzelsysteme zur Versionsverwaltung, Testwerkzeuge zur Unterstützung oder Automatisierung der Programmtests sowie Bug-Tracking bzw. Trouble-Ticket-Systeme, die nicht nur den Wartungsprozess begleiten und dokumentieren, sondern schon im Vorfeld der Wartungsmaßnahmen den Support unterstützen. Diese Werkzeuge wollen wir in den folgenden Abschnitten etwas näher betrachten. 8.1 Versionsverwaltungssysteme Für die Verwaltung der Artefakte der Softwareentwicklung und Softwarewartung sollte ein Versionsverwaltungssystem (Version Control System, VCS) zur Verfügung stehen. Dieses wird zur Erfassung der Erstellung und Änderung von Dokumenten oder Dateien eingesetzt. Alle Versionen eines Dokuments werden in einem Archiv (Repository) mit einem Zeitstempel und einer Benutzerkennung abgelegt, sodass Änderungen später wieder rekonstruiert werden können (Traceability). Die Systeme arbeiten hierbei inkrementell, d. h., es werden jeweils nur die Änderungen und nicht die gesamten versionierten Dokumente neu gespeichert. Versionsverwaltungssysteme werden nicht nur zur Verwaltung von Softwareprodukten und Artefakten, sondern auch bei Büroanwendungen und Content Management Systemen eingesetzt (vgl. z. B. Wikipedia). Sie müssen, falls sie im Unternehmen in dieser Verwendung schon vorhanden sind, für die Softwarewartung nicht gesondert beschafft werden. Grundsätzlich sollten bei Verwendung eines VCS zur Unterstützung der Softwarewartung alle Dateien (Artefakte), aber auch alle Informationselemente unterhalb der Dateiebene unter eine Versionskontrolle gestellt werden. Dies gilt beispielsweise für Konzepte, Entwurfsdokumentationen, Testfälle, Test- und Steuerdaten, Build-Produkte, Datendefinitionen der Datenbanken. Zu den wichtigsten Funktionen eines Version Control System (VCS) gehören die Protokollierung der Änderungen, Wiederherstellung von alten Ständen einzelner Dateien, Archivierung der einzelnen Stände eines Projektes, Koordinierung des gemeinsamen Zugriffs mehrerer Entwickler auf eine Datei, gleichzeitige Entwicklung mehrerer Entwicklungszweige (Branches) eines Projektes. Kapitel 8

17 91 Vorteilhaft ist die Verwaltung hierarchischer Beziehungen (Use-Beziehungen), um Zusammenhänge zwischen den Dokumenten herzustellen und Hierarchien zu erkennen. Ferner muss die Möglichkeit der Identifikation der Autoren (audit trail) geboten werden. Die Dokumentbezeichnungen sollten auch für Zweige der Weiterentwicklung frei wählbar sein und die Möglichkeit besitzen, Produktvarianten abzubilden. Den Vorgang, bei dem ein Dokument als Arbeitsdatei zur Bearbeitung aus dem Repository kopiert wird, bezeichnet man als Check-out, den umgekehrten Vorgang als Check-in. Zur Steuerung dieser Vorgänge gibt es unterschiedliche Organisationsprinzipien für die Versionsverwaltung, für die üblicherweise Datenbanksysteme genutzt werden. Lokale Versionsverwaltung Die Dokumente werden lokal gespeichert und es wird, wie bei Büroanwendungen üblich, jeweils nur eine lokal verfügbare Datei versioniert. Zentrale Versionsverwaltung Diese Verwaltung ist als Client-Server-System aufgebaut. Zugriffe auf das Repository können auch über das Netz erfolgen. Die Versionsgeschichte ist hierbei im Repository auf dem Server hinterlegt. Eine Rechteverwaltung sorgt dafür, dass nur berechtigte Personen neue Versionen im Archiv abholen und ablegen können. Verteilte Versionsverwaltung Die verteilte Versionsverwaltung verwendet kein zentrales Repository. Jeder, der an dem verwalteten Projekt arbeitet, hat ein eigenes Repository und kann dieses mit jedem beliebigen anderen Repository abgleichen. Die Versionsgeschichte ist dadurch verteilt. Änderungen können lokal verfolgt werden, ohne eine Verbindung zu einem Server aufbauen zu müssen. Im Gegensatz zur zentralen Versionsverwaltung kommt es nicht zu einem Konflikt, wenn mehrere Benutzer dieselbe Version einer Datei bearbeiten und ändern. Die sich widersprechenden Versionen existieren zunächst parallel und können weiter geändert werden. Sie können später automatisch oder manuell durch einen Integrator in einer neuen Version zusammengeführt werden. Bei der Nutzung zentraler oder verteilter Versionssysteme stehen zwei alternative Arbeitsweisen zur Verfügung: Lock Modify Write und Lock Modify Merge. Lock Modify Write Eine dieser Arbeitsweisen bezeichnet man als Lock Modify Unlock oder Lock Modify Write. Zu benutzende Dateien müssen vor einer Änderung durch den Benutzer gesperrt und nach Abschluss der Änderung zurückgeschrieben und/oder wieder freigegeben werden. Während sie gesperrt sind, verhindert das System Änderungen durch andere Benutzer. Der Vorteil dieses Konzeptes liegt darin, dass kein Zusammenführen von Versionen erforderlich ist, da immer nur ein Entwickler die Datei exklusiv bearbeiten kann. Nachteilig kann sein, dass bei zahlreichen Benutzern längere Wartezeiten entstehen, wenn Dokumente durch Bearbeiter längere Zeit gesperrt werden. Kapitel 8

18 92 Lock Modify Merge Ein Versionssystem, das nach diese Arbeitsweise arbeitet, lässt an einer Datei gleichzeitige Änderungen durch mehrere Benutzer zu. Anschließend werden diese Änderungen automatisch oder manuell durch einen Integrator zusammengeführt (Merge). Die Arbeit der Entwickler wird wesentlich erleichtert. Änderungen müssen nicht im Voraus angekündigt werden, Dateien werden nicht blockiert. Es können mehrere Entwickler auch räumlich getrennt effizient zusammenarbeiten, wie es beispielsweise bei Open-Source-Projekten häufig der Fall ist. Ein direkter Kontakt zwischen den Entwicklern ist nicht erforderlich. Bei zahlreichen Änderungen kann automatisches Zusammenführen problematisch sein, wenn von einer Ausgangsversion synchron zwei Tochterversionen erzeugt wurden. Für Quellcode-Dateien wurden Strategien entwickelt, die man als Syntactic Merge und als Semantic Merge bezeichnet. Im ersten Fall werden syntaktische Fehler angezeigt. Im zweiten Fall werden Situationen erkannt, in denen das Verhalten des Ergebnisses in Widerspruch zu dem Verhalten der Ausgangsversion steht. Für die zentrale und verteilte Administration von Versionsnummern gibt es zahlreiche Open-Source- und proprietäre SW-Werkzeuge. Für die zentrale Verwaltung stehen beispielsweise zur Verfügung: Open-Source-Software wie RCS (Revision Control System), CVS (Current Versions System), Apache Subversion (SVN) Verwaltung oder TortoiseSVN (unter Windows). Als proprietäre Systeme stehen beispielsweise IBM Rational Synergy oder IBM Rational Clear Case zur Verfügung. Für die verteilte Verwaltung werden u. a. das System Git (d. h. Blödmann) zur Versionsverwaltung des Linux-Kernels oder das proprietäre Werkzeug BitKeeper angeboten. Bei den proprietären Lösungen wird meist versucht, das Versionsmanagement mit dem Konfigurationsmanagement zu kombinieren oder in ein solches System zu integrieren. Die wichtigsten Werkzeuge zur Unterstützung der Wartung sind Testwerkzeuge, Systeme zur Versionsverwaltung und Bug-Tracking bzw. Trouble-Ticket-Systeme. Versionsverwaltungssysteme unterstützen die Verwaltung von Versionen aller Artefakte der Softwareentwicklung. Versionsverwaltungen übernehmen insbesondere Funktionen wie die Protokollierung und Wiederherstellung bei Änderungen, die Archivierung sowie die Koordination der Zugriffe bei gemeinsamer Nutzung. Mit der lokalen, der zentralen und der verteilten Versionsverwaltung gibt es drei verschieden Arbeitsweisen dieser Systeme, wobei die verteilte Verwaltung hinsichtlich der Kooperation mehrerer Entwickler die größte Flexibilität bietet und heute in vielen Open-Source-Projekten der Softwareentwicklung genutzt wird. 8.2 Testwerkzeuge Keine Aktivität der Softwarewartung ist mehr von Werkzeugen abhängig als das Testen. Innerhalb der möglichen Test- und Prüfverfahren sind Testwerkzeuge, insbesondere bei der Durchführung von Regressionstests, unentbehrlich. Bei häufiger Wiederholung der Tests ist eine manuelle Vorbereitung, Durchführung und Auswertung der Testergebnisse nicht mehr zu bewältigen, sodass man bei Regressionstests den größten Nutzen mit dem Einsatz von Testwerkzeugen und einer Testautomatisierung erzielen Kapitel 8

19 93 kann. Häufig sind umfangreiche Regressionstests erst mit dem Einsatz von Werkzeugen praktisch sinnvoll durchführbar. Prinzipiell sind folgende Aktivitäten, durch Werkzeuge unterstützt, automatisierbar: P Testfallerstellung mit Testdatenerstellung und Testskripterstellung, P Testdurchführung, P Testauswertung, P Testdokumentation, P Testadministration. Der kritische Punkt einer Automatisierung ist die Erstellung eines Testskripts. Hierbei muss die in einer höhersprachigen Beschreibung formulierte Spezifikation des Testfalls programmiert werden, z. B. mit hierfür geeigneten Skriptsprachen (Tcl, Perl, Phyton), mit imperativen Sprachen oder mit objektorientierten Ansätzen (JUnit). Für die (automatisierte) Durchführung von Regressionstests werden beispielsweise folgende Testwerkzeuge benötigt: Testplaneditor: In der Regel ein XML-fähiger Editor. Testfalleditor: Für die Bearbeitung von XSL- und XML-Dokumenten. Testfalldatenbank: Zur Aufbewahrung der Testfälle, der Codes, der Dokumentation und anderer Artefakte. Die Datenbank sollte die Verwaltung komplexer XML-Dokumente ermöglichen. Testdateneditor: Für die Verwaltung und Generierung komplexer Datensätze. Testtreiber: Um Klassen und Komponenten über ihre interne Systemschnittstelle oder um bei Dialogsystemen mit Systemtreibern über externe Schnittstellen die Benutzerschnittstellen (Benutzeroberflächen) zu testen. Werkzeuge für die Datenprüfung: Um Veränderungen und Abweichungen der Testdaten von den Sollwerten zu prüfen. Dynamische Analysatoren: Um die Codeüberdeckung zu messen oder Testfälle durch den Code zu verfolgen. Statische Analysatoren: Um Codeanalysen durchzuführen, Testfälle zu ermitteln und Komplexitätsmetriken zu ermitteln. Auf dem Softwaremarkt werden zahlreiche Testwerkzeuge angeboten. Gute Marktübersichten mit Bewertungen finden Sie beispielsweise unter: und Man sollte jedoch beachten, dass viele Tests sich nicht automatisieren lassen und in zeitraubender Arbeit manuell durchgeführt und überprüft werden müssen. Darüber hinaus sollte man in Erinnerung behalten, dass die Nutzung von Testwerkzeugen auch die hierfür entsprechende Qualifikation und Erfahrung des Anwenders erfordert, um damit die gewünschten Ergebnisse zu erzielen. Gerade in diesem komplexen Bereich des Softwareengineering gilt der bekannte Spruch: "A fool with a tool is still a fool." (Grady Booch, Entwickler der UML). Kapitel 8

20 94 Testwerkzeuge sollten alle Aktivitäten des Testens unterstützen, insbesondere die Testfallerstellung, die Testdurchführung, die Auswertung, die Dokumentation und die Testadministration. Alle heute eingesetzten Editor-Werkzeuge sollten in der Lage sein, XML- und XSL-Dokumente zu verwalten und die Automatisierung bei der Codeanalyse sowie bei der Erstellung und Auswertung der Tests, insbesondere der Regressionstests, zu ermöglichen. 8.3 Bug-Tracking-Systeme Aufgaben Bug-Tracking-Systeme, oder kurz Bugtracker, dienen der Verfolgung von Fehlern, Störungen und Problemen in Softwaresystemen. Es handelt sich hierbei um Fallbearbeitungssysteme (Trouble-Ticket-Systeme) für die Softwareentwicklung, die als Werkzeug eingesetzt werden, um Programmfehler zu erfassen und zu dokumentieren. Mit ihnen werden oft interaktiv und im Intranet über ein Unternehmensportal auch Zustands- oder Feature-Berichte geschrieben. Das zentrale Element dieser Systeme sind Trouble-Tickets (TT), die genau einen Störfall beschreiben. Aufgabe eines Trouble-Tickets ist es, den Lebenszyklus einer Störung von der Entdeckung über die Eingrenzung bis hin zur Lösung oder Beseitigung zu dokumentieren und zu Auswertungszwecken zur Verfügung zu stellen. Die Bezeichnung Trouble-Ticket (TT) kann als Sammelbegriff für Software Problem Report (SPR) und Modification Request (MR) verwendet werden. Neben Programmfehlern können Bugtracker auch andere Verbesserungsvorschläge und Wünsche der Nutzer oder allgemeine Vorgänge aufnehmen. Man spricht in diesem Fall von Issues (Angelegenheiten, Vorgänge) und von Issue-Tracking-Systemen, da sich dieser Ausdruck nicht nur auf Programmfehler beschränkt. In der Regel werden die Berichte elektronisch erfasst. In der Praxis geschieht dies meist mittels sog. User-Helpdesk-Systeme (UHD). Diese bieten spezielle Funktionen, die die Kommunikation und Problemlösung zwischen Anwendern und der Supportorganisation erleichtern, beispielsweise die Bereitstellung eines Web-Frontends, das Suchen ähnlicher Probleme und Lösungen sowie den Informationsaustausch und Benachrichtigungen per Nutzung und Beteiligte Bug-Tracking-Systeme dienen der Kommunikation und können von Benutzern, Testern, Entwicklern und dem Management genutzt werden. Benutzern kann dabei entweder allein lesender Zugriff auf die Bug-Tracking-Datenbank gegeben werden, sodass sie nur feststellen können, ob ein bestimmtes Fehlerverhalten bereits bekannt ist und wie weit dessen Behebung fortgeschritten ist, oder auch Kapitel 8

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

Was versteht man unter Softwarequalität?

Was versteht man unter Softwarequalität? Was versteht man unter? ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareproduktes, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Was ist

Mehr

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

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

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Einführung in die SWE

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

Mehr

31.01.2013. Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle

31.01.2013. Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle Vorlesung Programmieren Versionskontrolle Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/pfisterer Versionskontrollsysteme Wie organisiert man die

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Software-Maintenance SOFTWARE-MAINTENANCE. Factsheet

Software-Maintenance SOFTWARE-MAINTENANCE. Factsheet SOFTWARE-MAINTENANCE Factsheet Seite 2/6 -Service: Qualifiziert, transparent und individuell. Für verbesserte Prozesse im Software-Lifecycle Software-Systeme nehmen heute in nahezu allen Unternehmensbereichen

Mehr

Die Phasen der Software-Entwicklung

Die Phasen der Software-Entwicklung Die Phasen der Software-Entwicklung c OSTC GmbH, T. Birnthaler 2011-2015 V1.7 [sw-entwicklung-phasen.txt] 1 Übersicht Die Entwicklung von Software im Rahmen eines Projekts umfasst im wesentlichen die Phasen

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 1 Software Engineering: Überblick Kapitel 1 Software Engineering: Überblick 2 Ziele Verstehen, womit sich die Disziplin

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Softwarewartung auslagern

Softwarewartung auslagern Softwarewartung auslagern Die Wahl zwischen struktureller Kopplung und absehbarem Misserfolg Session T10 (45 ) 5. Mai 2009 www.software-wartung.net Copyright Siemens AG 2009. Alle Rechte vorbehalten Agenda

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Grundlagen des Software Engineering

Grundlagen des Software Engineering Grundlagen des Software Engineering Teil 1: SW-Management Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann Einleitung Historie des Konfigurationsmanagements:

Mehr

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Erfahrungen aus der industriellen Praxis Fraunhofer IESE Kaiserslautern Inhalt Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Mehr

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

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

Mehr

Softwaretests. Werkzeuge zur Automatisierung. Thementag Wer testet, ist feige. Autor: für 24.06.2009. Markus Alvermann.

Softwaretests. Werkzeuge zur Automatisierung. Thementag Wer testet, ist feige. Autor: für 24.06.2009. Markus Alvermann. Softwaretests Werkzeuge zur Automatisierung für Thementag Wer testet, ist feige 24.06.2009 Autor: Markus Alvermann Seite 2 / 39 Agenda Motivation Versionsverwaltung Build-Tools Unit-Tests GUI-Tests Continuous

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Software Engineering in

Software Engineering in Software Engineering in der Werkzeuge für optimierte LabVIEW-Entwicklung Folie 1 Best Practices Requirements Engineering Softwaretest Versionsmanagement Build- Automatisierung Folie 2 Arbeiten Sie im Team?

Mehr

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

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

Mehr

Projektmanagement. Projektmanagement

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

Mehr

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

Softwaretechnik (Medieninformatik) Überblick

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

Mehr

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement

Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Vorlesung Software-Wartung Änderungs- und Konfigurationsmanagement Dr. Markus Pizka Technische Universität München Institut für Informatik pizka@in.tum.de 3.3 Änderungsmanagement (CM) Evolution der Software

Mehr

Einführung in Verteilte Versionskontrollsysteme. am Beispiel von Git

Einführung in Verteilte Versionskontrollsysteme. am Beispiel von Git Einführung in Verteilte Versionskontrollsysteme am Beispiel von Git Diplominformatiker (BA), Git Benutzer seit 2009 Daniel Böhmer Leibniz Institut für Troposphärenforschung 8. März 2012 Verteilte Versionskontrollsysteme/Git

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15

Mehr

3.4 Konfigurationsmanagement (SCM)

3.4 Konfigurationsmanagement (SCM) 3.4 Konfigurationsmanagement (SCM) "Das KM stellt einen Mechanismus zur Identifizierung, Lenkung und Rückverfolgung der Versionen jedes Softwareelements dar. In vielen Fällen sind auch frühere, nach wie

Mehr

Quellcodeverwaltung mit SubVersion

Quellcodeverwaltung mit SubVersion Access-Stammtisch-Stuttgart 06.05.2010 Quellcodeverwaltung mit SubVersion Thomas Möller, www.team-moeller.de Vorstellung Thomas Möller dipl. Sparkassenbetriebswirt Arbeit mit Access seit 1997 Seit 2000

Mehr

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung 2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer Beitrag von Peter Küsters Formen des Datentransfers bei der Erfassung von Websites Im folgenden werden Methoden und Software zur Erfassung vorgestellt.

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Automatisierte Regressionstests per Knopfdruck sparen Zeit und Ressourcen sichern die Qualität schonen die Nerven

Automatisierte Regressionstests per Knopfdruck sparen Zeit und Ressourcen sichern die Qualität schonen die Nerven Automatisierte Regressionstests per Knopfdruck sparen Zeit und Ressourcen sichern die Qualität schonen die Nerven Dipl.-Inf (FH) Matthias Müller 09.06.2010 Regressionstests Unter einem Regressionstest

Mehr

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt Inhalt 1 Einführungsveranstaltung 1.1 Ziel der Veranstaltung Warum Qualität? Inhalt der Veranstaltung 1.2 Formaler Ablauf der Veranstaltung 1.3 Übungs- und Gruppeneinteilung 1.4 Bewertungskriterien mittels

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1.

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1. Agile Testing Der agile Weg zur Qualität von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner 1. Auflage Hanser München 2013 Verlag C.H. Beck im Internet: www.beck.de

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung Testen II (Management, Tools) Daniela Rose Fachgebiet Softwaretechnik und Systemgestaltung 12.12.2007 Gliederung 1. Motivation 2. Der grundlegende Testprozess 3. Testen im Softwareentwicklungsprozess 4.

Mehr

Software Engineering

Software Engineering Software Engineering Informatik II. 10. Software-Entwicklung Konfigurations-Management Dipl.-Inform. Hartmut Petters Vorwort was ich noch zu sagen hätte... Basis dieser Vorlesung sind vor allem die folgenden

Mehr

Testmanagement. Dirk Tesche

Testmanagement. Dirk Tesche Testmanagement Dirk Tesche Agenda Einführung in die Thematik Testarten Testprozess Agile Methoden und Techniken Testautomatisierung Eingrenzung und Motivation Abbildung entnommen aus: www.campero.de Ziele

Mehr

Testen von Data-Warehouse- und Business-Intelligence-Systemen

Testen von Data-Warehouse- und Business-Intelligence-Systemen Edition TDWI Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte von Herbert Stauffer, Beat Honegger, Hanspeter Gisin 1. Auflage Testen von Data-Warehouse- und

Mehr

[DIA] Webinterface 2.4

[DIA] Webinterface 2.4 [DIA] Webinterface 2.4 2 Inhalt Inhalt... 2 1. Einleitung... 3 2. Konzept... 4 2.1 Vorteile und Anwendungen des... 4 2.2 Integration in bestehende Systeme und Strukturen... 4 2.3 Verfügbarkeit... 5 3.

Mehr

Subversion als Werkzeug in der Software-Entwicklung Eine Einführung. Tobias G. Pfeiffer Freie Universität Berlin

Subversion als Werkzeug in der Software-Entwicklung Eine Einführung. Tobias G. Pfeiffer Freie Universität Berlin Subversion als Werkzeug in der Software-Entwicklung Eine Einführung Tobias G. Pfeiffer Freie Universität Berlin Seminar DG-Verfahren, 9. Juni 2009 Voraussetzungen/Ziele des Vortrags Situation Der Zuhörer

Mehr

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

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

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

Übungsaufgaben zum Software Engineering: Management

Übungsaufgaben zum Software Engineering: Management Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie

Mehr

Softwaretechnik. Prof. Dr.-Ing. habil Ilka Philippow Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik

Softwaretechnik. Prof. Dr.-Ing. habil Ilka Philippow Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik login: pw: Prof. Dr.-Ing. habil Fakultät für Informatik und Automatisierung FG Softwaresysteme/Prozessinformatik email: ilka.philippow@tu-ilmenau.de Tel. 69 2826 Sekr. 69 2870, Frau Meusel, Zuse Bau Zi

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

IV::SOLUTIONFRAMEWORK

IV::SOLUTIONFRAMEWORK IV::SOLUTIONFRAMEWORK EINFÜHRUNG Das IV::SolutionFramework ist die Antwort der INTERVISTA AG auf die Anforderungen an moderne IT Entwicklungsprojekte. Effiziente Vorgehensmodelle und die Einführung von

Mehr

Versionskontrollsysteme

Versionskontrollsysteme Versionskontrollsysteme Erfassung von Änderungen an Dateien Protokollierung von Änderungen Wiederherstellung alter Zustände Archivierung der gesamten Historie Koordinierung des gemeinsamen Zugriffs Verzweigung

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Versionsverwaltung mit git. Christoph Knabe FB VI 17.04.2014

Versionsverwaltung mit git. Christoph Knabe FB VI 17.04.2014 Versionsverwaltung mit git Christoph Knabe FB VI 17.04.2014 Inhalt Probleme bei Software-Entwicklung Begriffe in git Geschichte von git Installation Was ist verteilt an git? Mischen verteilter Änderungen

Mehr

Projektmanagement-Plan

Projektmanagement-Plan Applikationsentwicklung FS14 Gruppe 20 Horw, 29.05.2014 Bontekoe Christian Estermann Michael Rohrer Felix Autoren Bontekoe Christian Studiengang Informatik - Software Systems (Berufsbegleitend) Adresse

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services Wir schützen Ihre Investitionen Qualitätssicherung nach Maß IT Quality Services Sicherheit, die senkt Mit den IT Quality Services schützen Sie Ihre Investitionen Ohne Qualitätssicherung Mit Qualitätssicherung

Mehr

Projektmanagement: Prozessmodelle

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

Mehr

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

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

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

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

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

Mehr

Requirements Analysis Document

Requirements Analysis Document Requirements Analysis Document 1. Einleitung Dieses Dokument beschreibt die Anforderungen an ein automatisches Korrektur- und Abgabesystem für Uebungen mit dem Ziel einer Arbeitserleichterung für Assistenten.

Mehr

Informationssystemanalyse Personal Software Process 8 1

Informationssystemanalyse Personal Software Process 8 1 Informationssystemanalyse Personal Software Process 8 1 Personal Software Process Sehr eng mit dem CMM hängt der PSP (Personal Software Process) zusammen. Der PSP ergänzt das organisationsweite CMM um

Mehr

Methoden und Werkzeuge des Konfigurationsmanagements

Methoden und Werkzeuge des Konfigurationsmanagements Methoden und Werkzeuge des Konfigurationsmanagements Zunächst ein paar Fragen:! Was ist euer Bild des Konfigurationsmanagements?! Welche Aufgaben hat eurer Meinung nach das Konfigurationsmanagement?! Wer

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter

WSR 2004. Softwarewartung und Prozessmodelle in Theorie und Praxis. Urs Kuhlmann Andreas Winter WSR 2004 Softwarewartung und Prozessmodelle in Theorie und Praxis Urs Kuhlmann Andreas Winter Universität Koblenz-Landau 1 Gliederung Wartungsbegriff Prozessmodelle Fallstudien Problembereiche Fazit 2

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014 Programmierprojekt Anne0e Bieniusa Sommersemester 2014 Phasen der So;ware- Entwicklung Planungsphase DefiniConsphase Entwurfsphase ImplemenCerungsphase Testphase Wasserfall- Modell Einführungs- und Wartungsphase

Mehr

Software Configuration Management (SCM)

Software Configuration Management (SCM) Software Configuration Management () und n Einzelarbeit Namensgebung und Nummerierung Anleitung : Problemsituationen beim Arbeiten im Team Mehrere Entwickler ändern die gleichen Klassen Die Weiterentwicklung

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Subversion. von Stefan Arndt, Christian Autermann und Dustin Demuth. 5. November 2009

Subversion. von Stefan Arndt, Christian Autermann und Dustin Demuth. 5. November 2009 Subversion von Stefan Arndt, Christian Autermann und Dustin Demuth 5. November 2009 Inhaltsverzeichnis 1 Versionierung 1 1.1 Zweck von Versionierung................................. 1 1.2 Geschichtliches......................................

Mehr

Test-Karussell. Automatisierte Qualitätssicherung im Round-Trip. Test-Karussell. Folie 1 08. November 2006

Test-Karussell. Automatisierte Qualitätssicherung im Round-Trip. Test-Karussell. Folie 1 08. November 2006 Automatisierte Qualitätssicherung im Round-Trip Folie 1 Test und Automatisierung Qualitätssicherung schafft (nur) Transparenz und ist aufwändig und teuer Testen kann die Qualität nicht verbessern 40-50%

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Praktikum Software Engineering: Verfahren und Werkzeuge

Praktikum Software Engineering: Verfahren und Werkzeuge Praktikum Software Engineering: Verfahren und Werkzeuge Lehrstuhl für Software Engineering (Informatik 11) Verfahren und Werkzeuge Seite 1 Software Engineering Absichten, Aufgaben Systemnutzung Anforderungsspezifikation

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Permanente Integration Einstellung und Prozess versus Werkzeuge

Permanente Integration Einstellung und Prozess versus Werkzeuge Consulting Guild AG Methodenberatung für Projekte im 21. Jahrhundert Permanente Integration Einstellung und Prozess versus Werkzeuge Inhalt: Einleitung 1 Worum geht's hier überhaupt? 2 Überblick 2 Permanente

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Code-Quality-Management

Code-Quality-Management Code-Quality-Management Technische Qualität industrieller Softwaresysteme transparent und vergleichbar gemacht von Frank Simon, Olaf Seng, Thomas Mohaupt 1. Auflage Code-Quality-Management Simon / Seng

Mehr

Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung

Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung Der Stammesverbund Inhaltsverzeichnis Software-Qualitätssicherung Fachliche Testautomatisierung Test-Outsourcing Test-Virtualisierung

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

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

Mehr

Bugtracking Tools codecentric GmbH

Bugtracking Tools codecentric GmbH Bugtracking Tools codecentric GmbH Rainer Vehns, Java Enterprise in der Deutschen Rentenversicherung. 29. Oktober 2008 Seite 1 Agenda Bug Tracking Ziele und Abgrenzung Anforderungen an Bugtracking Tools

Mehr

Redmine, das Projekt Management Werkzeug

Redmine, das Projekt Management Werkzeug Redmine, das Projekt Management Werkzeug Web Site: www.soebes.de Blog: blog.soebes.de Email: info@soebes.de Dipl.Ing.(FH) Karl Heinz Marbaise Agenda 1.Einführung 2.Installation 3.Übersicht 4.Features 5.Informationsquellen

Mehr

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

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

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth

Mehr

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Dipl.-Math. Hermann Will QADVICE Software+System Qualität Jamnitzerstr. 2, 81543 München hermann.will@qadvice.de Zusammenfassung.

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr