Softwaredokumentation und Softwarewartung
|
|
- Maike Clara Kästner
- vor 2 Jahren
- Abrufe
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
Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12
Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung
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
Entwicklungswerkzeuge
Entwicklungswerkzeuge Werner Struckmann & Tim Winkelmann 10. Oktober 2012 Gliederung Anforderungen Projekte Debugging Versionsverwaltung Frameworks Pattern Integrated development environment (IDE) Werner
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
Software Engineering. 11. Einführung und Wartung
Software Engineering 11. Einführung und Wartung Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Testen
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
Softwaretechnik (Allgemeine Informatik) Überblick
Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6
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
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
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
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
1. Grundbegriffe des Software-Engineering
1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen
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
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
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
Software Qualität Übung 1
1. Informationen 1.1 Formales Software Qualität Übung 1 Regressionstests mit JUnit Versionskontrolle mit CVS Bugtracking mit Bugzilla Abgabetermin: Freitag 20.April 2007, 18.00 CET (Central European Time)
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
Was versteht man unter Softwaredokumentation?
Was versteht man unter? Mit bezeichnet man die Dokumentation von Computer-Software. Sie erklärt für Anwender, Benutzer und Entwickler in unterschiedlichen Rollen, wie die Software funktioniert, was sie
Einführung in die Softwareentwicklung
Einführung in die Softwareentwicklung Thorsten Lemburg Universität Hamburg Seminar: Softwareentwicklung in der Wissenschaft 1 / 53 Einführung in die Softwareentwicklung - Thorsten Lemburg Gliederung 1.
Software-Wartung Grundbegriffe und Einordnung Der Wartungsprozeß
Software-Wartung Grundbegriffe und Einordnung Der Wartungsprozeß Marc Monecke monecke@informatik.uni-siegen.de Praktische Informatik Fachbereich Elektrotechnik und Informatik Universität Siegen, D-57068
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
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:
Software Engineering
Software Engineering Grundlagen, Menschen, Prozesse, Techniken von Jochen Ludewig, Horst Lichter 1. Auflage Software Engineering Ludewig / Lichter schnell und portofrei erhältlich bei beck-shop.de DIE
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
Programmierung im Grossen. Vorlesung 22: Konfigrationsmanagement. Themenübersicht. Bertrand Meyer. Bernd Schoeller bernd.schoeller@inf.ethz.
1 Letzte Aktualisierung: 29. Juli 2004 Programmierung im Grossen Bertrand Meyer 2 Vorlesung 22: Konfigrationsmanagement Bernd Schoeller bernd.schoeller@inf.ethz.ch Themenübersicht 3 Motivation Was ist
Versionsverwaltung GIT & SVN. Alexander aus der Fünten. Proseminar: Methoden und Werkzeuge, SS 2012. Lehrstuhl i9, Prof. Dr. T.
Versionsverwaltung GIT & SVN Alexander aus der Fünten Proseminar: Methoden und Werkzeuge, SS 2012 Lehrstuhl i9, Prof. Dr. T. Seidl RWTH Aachen Ablauf Was ist Versionsverwaltung? Arbeitsmodelle Lokale,
Was versteht man unter einem Softwareentwicklungsmodell?
Softwareentwicklung Was versteht man unter einem Softwareentwicklungsmodell? Ein Softwareentwicklungsmodell ist ein für die Softwareentwicklung angepasstes Vorgehensmodell bei der professionellen ( ingenieursmäßigen
Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013
Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael
Software-Lebenszyklus
Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung
Framework zur Unterstützung von Unit-Tests
JUnit Framework zur Unterstützung von Unit-Tests Automatisierte Ausführung von Tests Ideen dahinter Testgetriebene Entwicklung: Erst testen, dann programmieren Alle Testfälle häufig ausführen (nach jeder
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
Ü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
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
Software Engineering
Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,
Kooperatives Testen Basis auch zur Testautomatisierung während der Softwareentwicklung. Dipl. Inform. Hans-Josef Eisenbach
Kooperatives Testen Basis auch zur Testautomatisierung während der Softwareentwicklung Dipl. Inform. Hans-Josef Eisenbach Der rote Faden Motivation zum Testen während der Softwareentwicklung Das Testkonzept
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?
Softwaretechnik. Fomuso Ekellem WS 2011/12
WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von
Versionskontrollsysteme
Versionskontrollsysteme Erfassung von Änderungen an Dateien Protokollierung von Änderungen Wiederherstellung alter Zustände Archivierung der gesamten Historie Koordinierung des gemeinsamen Zugriffs Verzweigung
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
Software - Testung ETIS SS05
Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks
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
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,
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%
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
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
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/
Prozess-Modelle für die Softwareentwicklung
Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell
Drei Jahre mit Polarion bei Fresenius Medical Care. Stuttgart, Oktober 2012
Drei Jahre mit Polarion bei Fresenius Medical Care Stuttgart, Oktober 2012 Polarion Users Conference 2012, Drei Jahre mit Polarion bei Fresenius Medical Care, Jürgen Lehre (c) Copyright 31/08/2012 Fresenius
Software Engineering. Sommersemester 2012, Dr. Andreas Metzger
Software Engineering (Übungsblatt 1) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Besonderheiten und Eigenschaften von Software; Interne und Externe Eigenschaften 1 Aufgabe 1.1 Software
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
1 Einleitung zum Thema Softwaremigration 1
xi 1 Einleitung zum Thema Softwaremigration 1 1.1 Die Motivation für Softwaremigration........................ 1 1.2 Zum Zustand der IT in der betrieblichen Praxis................. 4 1.3 Alternativen zur
13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES
13 Anhang A: Erfüllung der Norm ISO 9000 durch Hinweis Einleitung Eine der wesentlichsten Grundlagen für die Qualitätssicherung in einem Unternehmen ist die Normenserie «ISO 9000», insbesondere ISO 9001:1994
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:
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
Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003
Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen
Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen
White Paper Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen Die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen
Konfigurationsmanagement mit Subversion, Ant und Maven
Gunther Popp Konfigurationsmanagement mit Subversion, Ant und Maven Grundlagen für Softwarearchitekten und Entwickler 2., aktualisierte Auflage Gunther Popp gpopp@km-buch.de Lektorat: René Schönfeldt Copy-Editing:
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
Testen Prinzipien und Methoden
Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,
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:
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:
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.
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
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.
Qualitätssicherungskonzept
Qualitätssicherungskonzept Web Annotation mit Fragment Ids Gruppe: swp12-9 Inhaltsverzeichnis 1. Dokumentationskonzept...2 1.1. Quelltexte...2 1.2. Änderungsdokumentation...4 1.3. Modellierungsdokumentation...4
Qualitätsmanagement im Projekt
Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung
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
Einführung in Subversion
Einführung in Subversion Benjamin Seppke AB KOGS Dept. Informatik Universität Hamburg Was ist Subversion? Ein Server-basiertes Versions-Verwaltungs- System Ermöglicht mehreren Benutzern die gemeinsame
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
CRM-Komplettpaket zum Fixpreis
Richtig informiert. Jederzeit und überall. CRM-Komplettpaket zum Fixpreis Leistungsbeschreibung CAS Software AG, Wilhelm-Schickard-Str. 8-12, 76131 Karlsruhe, www.cas.de Copyright Die hier enthaltenen
Qualitätssicherung unter dem Open Source Entwicklungsmodell
Qualitätssicherung unter dem Open Source Entwicklungsmodell Markus Böger 10. Juli 2009 Agenda Einleitung Grundlagen Entstehung eines Open Source Projektes Probleme des Open Source Entwicklungsmodells und
Die Softwareentwicklungsphasen!
Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.
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
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
Ü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
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...
Leitfaden zur Installation von BitByters.Backup
Leitfaden zur Installation von BitByters.Backup Der BitByters.Backup - DASIService ist ein Tool mit dem Sie Ihre Datensicherung organisieren können. Es ist nicht nur ein reines Online- Sicherungstool,
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
Konfigurationsmanagement. Referat im Fachgebiet Software Engineering Referent: Philipp Schwarzhuber Datum: 11. November 2002
Referat im Fachgebiet Software Engineering Referent: Philipp Schwarzhuber Datum: 11. November 2002 - Inhalt - Überblick - Problemstellung - Standards - Artefakte - Erstellung des KM-Plans - Umsetzung des
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
Produktbeschreibung. CoPFlow Prozessmanagement. einfach intuitiv effizient. Web-basiertes Prozessmanagement für den Arbeitsplatz
Prozessmanagement Web-basiertes Prozessmanagement für den Arbeitsplatz einfach intuitiv effizient Prozesse dokumentieren, analysieren und verbessern Prozessbeschreibungen und Arbeitsanweisungen für den
Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse. Dr. Thorsten Arendt Marburg, 13. November 2014
Konfigurationsmanagement und Evolution: Änderungsverwaltung und Repository-Analyse Dr. Thorsten Arendt Marburg, 13. November 2014 Überblick Was ist eine Änderungsverwaltung und warum braucht man sie? Fehlerverfolgung
CWA Flow. Prozessmanagement und Workflow-Management. Workflow- und webbasierte Lösung. Per Browser einfach modellieren und automatisieren
CWA Flow Prozessmanagement und Workflow-Management Per Browser einfach modellieren und automatisieren Workflow- und webbasierte Lösung Workflow- und webbasierte Lösung Webbasierte Prozessmanagement und
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
Testen. SEPR Referat: Testen - Oliver Herbst
Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt
IT-Projekt-Management
IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über
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
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
Werkzeuge für das Softwarekonfigurationsmanagement
Werkzeuge für das Softwarekonfigurationsmanagement Hauptseminar Frank Herrmann Technische Universität Dresden Institut für Systemarchitektur Gliederung Ziele des Softwarekonfigurationsmanagements SCM-Standardwerkzeug
visionapp Platform Management Suite Save Event Version 2.0 Technische Dokumentation
visionapp Platform Management Suite Save Event Version 2.0 Technische Dokumentation Copyright visionapp GmbH, 2002-2006. Alle Rechte vorbehalten. Die in diesem Dokument enthaltenen Informationen, Konzepte
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
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
Konfigurationsmanagement
Konfigurationsmanagement Universität zu Köln Historisch-Kulturwissenschaftliche Informationsverarbeitung Re-usable Content in 3D und Simulationssystemen Dozent: Prof. Dr. Manfred Thaller Referent: Jannes
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
Übung Einführung in die Softwaretechnik
Lehrstuhl für Informatik 3 RWTH Aachen Übung Einführung in die Softwaretechnik Lösungshinweise zum Übungsblatt 3 Aufgabe 6a) Welche Projekttypen gibt es, und wie ist deren Zusammenhang? Systementwicklung
EasternGraphics Produktunterlagen Anleitung zur Migration für pcon.update
2007-02-13 [BBA] 2007-02-14 [AWI] Hintergrund Zur Nutzung von pcon.update auf Ihrem System sind Anpassungen in Bezug auf Ihre pcon- Applikationen und OFML-Daten erforderlich. Dies trifft insbesondere dann
Technische Mitteilung. Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor
Technische Mitteilung Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor Informationen zum Dokument Kurzbeschreibung Dieses Dokument gibt Hinweise zur Konfiguration des RDBMS Oracle und von VIP ContentManager
OTRS-TFS-Konnektor. Whitepaper. Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg
OTRS-TFS-Konnektor Whitepaper Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg Tel: 0391 59801-0 Fax: 0391 59801-10 info@advanto-software.de Stand: Mai 2015 Inhaltsverzeichnis 1 Idee... 3 2
Software Engineering. 3. Analyse und Anforderungsmanagement
Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz
Agiles Testen. Handwerkszeug zur Prävention von Fehlern und technischen Schulden. Entwicklertag 2014. Lars Alvincz, Daniel Knapp
Agiles Testen Handwerkszeug zur Prävention von Fehlern und technischen Schulden Entwicklertag 2014 Lars Alvincz, Daniel Knapp 2 Agenda Ziel dieses Vortrags Grundzüge des agilen Testens Voraussetzungen