Wirtschaftsinformatik Vorlesung/Übung VBA

Card Set Information

Author:
huatieulans
ID:
296867
Filename:
Wirtschaftsinformatik Vorlesung/Übung VBA
Updated:
2015-02-25 13:47:46
Tags:
WS
Folders:
BWL
Description:
Klausur
Show Answers:

Home > Flashcards > Print Preview

The flashcards below were created by user huatieulans on FreezingBlue Flashcards. What would you like to do?


  1. Systementwicklung
    Systementwicklung beinhaltet die Gesamtheit der planenden, analysierenden, entwerfenden, ausführenden und prüfenden Tätigkeitenzur Schaffung eines neuen oder Änderung eines bestehenden Informationssystems.

    • Fundamental ist die Trennung in Spezifikation und Konstruktion
    • >Spezifikation: Festlegung, was ein System leisten soll
    • maßgeblich: Anwender
    • >Konstruktion: Festlegung, wie die Anforderungen erfüllt werden
    • maßgeblich: IT-Fachleute

    Softwaretechnische Aspekte, z.B. Programmierung, sind zunächst sekundär

    Systementwicklung erfolgt im Rahmen eines Projektes, d.h. einer einmaligen zeitlich befristeten Aufgabe, die von einem Projektteam aus Anwendern und IT-Spezialisten durchgeführt wird.
  2. Softwareentwicklung wird vermehrt zu einer Dienstleistung
    • Return on Investment
    • Benutzererwartungensteigen
    • Anforderungsstau
    • Vieles, was vom Auftraggeber/Anwendergewollt wurde, konnte man nicht umsetzen
    • Kommunikation zwischen Entwickler und Auftraggeber mit unterschiedlichem Domainwissen
  3. Risikofaktoren bei Systementwicklungen
    • Nicht ausreichende Präzision der Anforderungen 
    • Häufige Änderungen der Anforderungen 
    • Entwicklung der falschen Funktionalität
    • Unrealistische Zeit-und Kostenpläne
    • Probleme innerhalb des Projekt
    • >teamsorganisatorische Defizite
    • >mangelnde Qualifikation 
    • >Ausscheiden wichtiger Teammitglieder
    • >Missverständliche Formulierungen und Absprachen

    • Qualitätsmängel bei extern vergebenen Aufgaben
    • Verwendung der falschen Technologien
    • Unpassende Benutzerschnittstelle
    • Fehlende Akzeptanz der Anwender
  4. Probleme von Systementwicklungen
    • Die Entwicklung von Informationssystemen ist komplex, teuer und mit vielen Risiken behaftet
    • Systementwicklungen kosten häufig mehr und dauern länger als geplant
    • Etwa ein Drittel aller komplexen Systementwicklungen werden vor Fertigstellung abgebrochen
    • Viele Systeme funktionieren nicht wie geplant oder werden an den Anforderungen vorbeientwickelt

    • Beispiele
    • Denver International Airport wurde 18 Monate verspätet eröffnet 
    • Verzögerung verursachte 1 Million US Dollar Verlust –pro Tag
    • Grund: fehlerhafte Software zur Gepäcktransportsteuerung

    • Maut-System in Deutschland
    • Die verspätete Inbetriebnahme verursachte Einnahmeverluste nahezu in Milliardenhöhe
  5. Lösung komplexer Probleme mit vielen Personen
    • Erfordert
    • >OrganisatorischenPlan(Wer tut wann was?)
    • >Inhaltlichen Plan bzw. Konzeption(Wie soll das Ergebnis aussehen?)

    • •Jedes Systementwicklungs-Projekt hat aus der Sicht des Unternehmens einen einmaligen Charakter
    • •Es verläuft jedoch normalerweise nach einem allgemein gültigen Grundschema
    • •Dieses Grundschema berücksichtigt meist neben der reinen Softwareentwicklung auch die Ausgestaltung organisatorischer Aspekte
  6. VBA
    1. Machbarkeitsstudie (Ist-Zustand)
    • Machbarkeitsstudie soll Kosten und Ertrag der geplanten Systementwicklung abschätzen
    • Grobe Analyse des Problems mit Lösungsvorschlägen
    • Aufgaben
    • >Problem informell und abstrahiert beschreiben
    • >Verschiedene Lösungsansätze erarbeiten
    • >Kosten abschätzen und Angebot erstellen

    • Ergebnisse
    • Lastenheft(Beschreibung der Anforderungendes Auftraggebers)
    • Kalkulation und Projektplan
    • Angebot an Auftraggeber
  7. VBA
    2. Anforderungsdefinition (Soll-Konzept)
    • Exakte Festlegung, wasdas System leisten soll
    • Aber (noch) nicht wie die Leistungsmerkmale (technisch) erreicht werden
    • Aufgaben
    • Ist-Analyse: Beschreibung von Abläufen und Begriffen des Problembereichs
    • Soll-Konzept: Festlegung der Systemeigenschaften wie Funktionalität und Benutzerschnittstellen im Pflichtenheft
    • Bestimmen von Testfällen

    • Ergebnisse
    • Pflichtenheft= Anforderungsdefinitions-Dokument
    • Testplan
  8. VBA
    3. Analyse
    • In dieser Phase erfolgt eine Analyse der Anforderungen zum Zweck der weiteren Verfeinerung
    • Aufgaben
    • >Verfeinerung des Soll-Konzepts
    • >Erstellen einer groben Architektur
    • >Beschreibung von Ablauf und Struktur des zu erstellenden Systems

    • Ergebnis
    • Grobe Systemarchitektur (Modul-Definitionen)
    • Analysedokument
  9. VBA
    4. Entwurf
    • Im Systementwurf wird exakt festgelegt, wie die Funktionen der Software zu realisieren sind. Es wird der Bauplan der Software, die Softwarearchitektur, entwickelt
    • Aufgaben
    • Programmieren-im-Großen= Softwarearchitektur
    • Grobentwurf (Teilsysteme und -module)
    • Feinentwurf (Modulschnittstellen und Algorithmen)

    • Ergebnisse
    • Ausarbeitung der Module
    • Detaillierte Testpläne für Module und Komponenten
    • Entwurfsdokument
  10. VBA
    5. Implementierung und Test
    • Die eigentliche Umsetzungsphase, in der Module realisiert, getestet und in das endgültige System integrierteren
    • Aufgaben
    • Implementieren in einer Programmiersprache
    • Schrittweises Testen und Integrieren
    • Systemtests (α-Tests)

    • Ergebnis
    • Quellcode und dessen Dokumentation
    • Erstes fertiges System (α-Version)
    • Benutzerhandbuch
  11. VBA
    6. Auslieferung und Installation
    • Die Auslieferung und Inbetriebnahme der Software beim Kunden
    • •Diese Stufe findet meist in zwei Phasen statt

    • •Aufgaben
    • Auslieferungan ausgewählte Benutzer (β-Test)
    • Integration in die Zielumgebung
    • Auslieferung an alle Benutzer

    • •Ergebnis
    • Fertiges System (β-Version)
    • Akzeptanztestdokument
  12. VBA
    7. Wartung
    • Nach der ersten Auslieferung der Software beginnt das Elendder Systemwartung, das ca. 60% der gesamten Kosten ausmacht
    • Aufgaben
    • Fehler beheben
    • Anpassungen vornehmen
    • Verbesserungen einarbeiten

    • Ergebnisse
    • Fehlerbeschreibungen
    • Veränderungsvorschläge
    • Neue Versionen (Releases)
  13. Das Wasserfallmodell –Pro und Contra
    • Einteilung in klar abgegrenzte Phasen
    • Strukturierung des Entwicklungsprozesses
    • Phasenweise Ergebnisplanung und -kontrolle
    • Komplexitätsreduktion durch Teilphasen
    • Einsatz spezifischer Methoden und Werkzeuge

    • Schwäche von Phasenmodellen
    • Rein sequentielle feste Anforderungen sind oft unrealistisch
    • Kritisch ist die Qualität des Pflichtenheftes
    • Fehler werden häufig erst sehr spät erkannt

    Probleme mit dem Wasserfall

    • Zu Projektbeginn sind nur ungenaue Kosten-und Ressourcenabschätzungen möglich
    • Selbst ein gutes Pflichtenheft kann nie den Umgang mit dem fertigen System ersetzen, gutes Feedback kommt daher erst sehr spät
    • Es gibt Fälle, in denen zu Projektbeginn kein vollständiges Pflichtenheft erstellt werden kann (weil Anforderungen noch nicht klar sind)
    • Reale Softwareentwicklungs-Projekte verlaufen nie so sequentiell wie es das Wasserfallmodell impliziert

    Wir bleiben trotzdem beim Wasserfallmodell, weil‘s so schön einfach ist und die Konzepte auch in realistischeren Modellen zum Einsatz kommen
  14. Das V-Modell
    • Variante des Wasserfallmodells
    • Entwicklungsstandard der öffentlichen Hand (wird bei Behörden und der Bundeswehr eingesetzt)
    • Betonung liegt auf der Qualitätssicherung
    • Zu jeder Phase existiert ein zugehöriger Test, der die Artefakte jeder Phase testet, bevor sequentiell fortgefahren wird
  15. Das überlappende Phasenmodell
    • Oft wird zu einem späteren Zeitpunkt erkannt, dass man in einer früheren Phase wichtige Aspekte übersehen oder falsch eingeschätzt hat
    • Meilensteinplanungen, Pflichtenhefte und Prototypen durchlaufen so üblicherweise mehrere Änderungszyklen
    • Sequenzielles Vorgehen wird daher teilweise aufgeweicht
  16. Prototyping
    • Ein Prototyp ist eine ausführbare Vorversion eines Informationssystems, das zur genauen Erfassung der Anforderungen dient.
    • Vorteile des Prototyping
    • >Prototypen bilden eine Kommunikationsbasis für die Projektbeteiligten als Alternative zum Lesen vieler Seiten formaler Beschreibungen
    • >Benutzer können Anforderungen anhand eines Prototyps oft besser spezifizieren 
    • >Test der geplanten Benutzerschnittstelle (Look & Feel) durch Anwender
    • >Schnelle Bestimmung, welche Funktionen notwendig und welche überflüssig sind

    • Oft werden reine Oberflächen-Prototypen ohne dahinter liegende Funktionalität und Datenhaltung verwendet
    • Ein Prototyp ist noch lange kein Produktivsystem, da u.a. Aspekte wie Skalierbarkeit, Qualitätssicherung und Wartbarkeit nicht berücksichtigt werden
  17. Der Prototyping-Prozess
    • Prototyping kann helfen, die Anforderungen aufbauend auf einer Pilotversion iterativ zu verfeinern. Reine Wegwerf-Prototypen sind in der Praxis selten.
    • Vorteile
    • − Bei Unsicherheiten hinsichtlich der Anforderungen
    • − Bei hohem Grad an Benutzerinteraktion

    • Nachteile/Risiken
    • − Beim Übergang in ein betriebsfähiges System ist die Skalierung problematisch (hohe Datenmengen oder große Benutzerzahlen)
    • − Ad-hoch Änderungen nicht sorgfältig geplant

    - Die Folge ist ein schwer wattbares System
  18. Extreme Programming(XP)
    • „agile Entwicklung“ mit Betonung auf der Programmiertätigkeit
    • Wenige Regeln, die laufend je nach Projektbedingungen adaptiert werden
    • Geringe Bedeutung des formalisierten Vorgehens
    • Starker Fokus auf der Implementierunganstelle einer vorherigen Planung
    • Kleine Entwicklungsteams und häufige Iterationen sollen die Aufgaben klein und überschaubar halten
    • Pair Programminggegen Qualitätsrisiken
    • Reaktion auf den immer komplexer werdenden Managementprozesses in Entwicklungsprojekten
    • Vorgehen in vielen Open-Source-Projekten
  19. Vorgehensmodelle sind also das Allheilmittel?
    • Nein 
    • Vorgehensmodelle geben nur den Rahmen vor
    • Das primäre Ziel ist der Projekterfolg und nicht das Vorgehensmodell
    • Kein Vorschlag hat sich mit Breitenwirkung durchgesetzt
    • Es gibt weiterhin Risiken
    • „Folge dem Prozess und alles wird gut“-Mentalität
    • Hoher Koordinationsaufwand durch eine Vielzahl an Spezialisten für jeden Schritt
    • ParkinsonschesGesetz –gerade bei geringer wirtschaftlicher Kontrolle:
  20. Machbarkeitsstudie
    • Ist das neue System eine sinnvolle Investition?
    • Erfassung des organisatorischen und technischen Ist-Zustandes
    • >Prozesse, Aufgaben, Aufgabenträger, Arbeitsergebnisse
    • >Datenbasis (manuell bzw. maschinell)
    • >Material-und Belegflüsse, Schnittstellen, Berichtssysteme

    • Analyse und Bewertung des Ist-Zustandes
    • >Vergleich des Ist-Zustandes mit einem Idealsystem(real, fiktiv)
    • >Wunschvorstellungen aus Negativerfahrungen mit dem Ist-Zustand entwickeln
    • >Umsetzbarkeit der Wunschvorstellungen prüfen

    Wichtig: Glossar für einheitliche Projektterminologie
  21. Machbarkeitsstudie –Vorgehen und Techniken
    • Das fachliche Know-how der Anwenderist unverzichtbar! 
    • Erhebungstechniken
    • >Persönliche Interviews (wichtigste Methode!)
    • >Fragebogen
    • >Unterlagenstudium
    • >Konferenzen
    • >Beobachtungen

    • Interview
    • >Detaillierte Vorplanung mit vorbereitetem Fragenkatalog 
    • >Schaffung einer positiven Gesprächsatmosphäre
    • >Keine oder wenig Aufzeichnungenwährend des Interviews
    • >Anfertigung eines Berichtes mit: Namen, Zeit, Ort, Ergebnisse

    • Grundsätzliche Fehler bei InterviewsKritik an der bisherigen Abwicklung, IT-Fachausdrücke 
    • Missverständliche Eindrücke über Zweck der Systementwicklung (z.B. Abbau von Arbeitsplätzen)
    • Gesprächspartner einschüchtern oder sich einschüchtern lassen
  22. Machbarkeitsstudie –Vorgehen und Techniken (2)
    • Erfassung des organisatorischen und technischen Ist-Zustandes
    • Projektterminologie verstehen
    • Interviews, Unterlagen, Fragebögen, Workshops
  23. Ergebnis –das Lastenheft
    • 1)Beschreibung des Ist-Zustands
    • 2)Beschreibung der Ziele des Projekts
    • 3)Beschreibung der Schnittstellen –Mit Benutzern und anderen Systemen?
    • 4)Funktionale Anforderungen–Was soll das System können?
    • 5)Nichtfunktionale Anforderungen –Benutzbarkeit, Zuverlässigkeit, Effizienz, …
    • 6)Erste grobe Skizze des Entwicklungszyklus
    • 7)Lieferumfang und Abnahmekriterien

    „Das Lastenheft […] enthält zumeist noch eine inkonsistente und qualitativ formulierte Sammlung von zum Teil konkurrierenden Anforderungen an das Projekt.“
  24. Anforderungsdefinition (Soll-Konzept)
    • Im Lasterhaft wurden die Anforderungen beschrieben
    • Darauf aufbauend werden nun im Pflichtenheft Lösungsansätze dargelegt
    • (ohne Ausarbeitung der konkreten Umsetzung!)
    • Fachliche Spezifikation des zu entwickelnden Informationssystems
    • Formulierungsgrundsätze:So allgemein wie möglich
    • So einschränkend wie nötig
  25. Das Pflichtenheft als zentraler Bestandteil
    Das Pflichtenheft ist Grundlage jeder Softwareentwicklung!

    • Für den Anwender:
    • Dokumentation dessen, was die Software künftig leisten soll

    • Für den Analysten:
    • Dokumentation der Problemdomäne

    • Für den Entwickler:
    • Referenz zum Testen

    • Für den Auftraggeber:
    • Vertragsbestandteil
  26. Gliederung des Pflichtenhefts
    • 1. Zielbestimmung
    • Warum wird die Software überhaupt entwickelt?
    • 2. Produkteinsatz
    • Wie genau sieht das Problemumfeld aus?
    • Welche Strukturen und Abläufe existieren hier?
    • 3. Produktfunktionen
    • Was soll die Software leisten?
    • 4. Produktcharakteristiken
    • Wie soll die Software dies leisten?
    • Wo soll die Software dies leisten (Umgebung)?

    „Im Gegensatz zu einem Lastenheft handelt es sich bei einem Pflichtenheft um ein widerspruchsfreies, quantitativ formuliertes Zielsystem. “
  27. In welcher Form wird das Pflichtenheft verfasst?
    • 1. Zielbestimmung–Textuelle Beschreibung
    • 2. Produkteinsatz
    • 2.1 Beschreibung des Problembereichs–Textuelle Beschreibung & Illustrationen
    • 2.2 Glossar –Textuelles Nachschlagewerk für Fachbegriffe
    • 2.3 Modell des Problembereichs–Grafische Notation der Strukturen (UML)
    • 2.4 Geschäftsprozesse–Grafische Notation der Prozesse & Anwendungsfälle (UML)
    • 3. Produktfunktionen–Grafische Notation der Anwendungsfälle (UML)
    • 4. Produktcharakteristiken–Textuelle Beschreibung der nicht-funktionalen Anforderungen (Wartbarkeit, Benutzerfreundlichkeit, …)
  28. Abstraktion und Modellierung
    • Warum benötigen wir Modelle und Modellierungssprachen?
    • Abstraktion = Beschränkung auf das Wesentliche
  29. Informelle und formale Sprachen
    • Informelle Sprachen
    • Definierte Syntax
    • Keine präzise Semantikdefinition
    • Mehrdeutigkeiten möglich


    • Formale Sprachen
    • Definierte Syntax
    • Präzise definierte Semantik
    • Beispiel: arithmetische Ausdrücke:
  30. Wurzeln der UML
    • OMTObject Modeling Technique (James Rumbaugh et al.)
    • >Analyse datenintensiver Informationssysteme
    • >Insbesondere erweiterte ER-Diagramme

    • Booch-Methode(Grady Booch, Rational)
    • >Modellierung von Echtzeitsystemen und nebenläufigen Systemen
    • >Beeinflusst durch Programmiersprachen

    • OOSEObject-Oriented Software Engineering (Ivar Jacobson)
    • >Use-Case-orientierter Ansatz
    • >Insbesondere Geschäftsprozessmodellierung
  31. Unified Modeling Language (UML)
    • Standardisierte Notation für die Analyse, den Entwurf und die Dokumentation von Informationssystemen
    • UML Diagramme werden zur Visualisierung von Strukturen und Abläufenim Rahmen des Pflichtenhefts verwendet
    • Wir betrachten hier drei der wichtigsten Diagrammtypen
  32. Verteilungsdiagramm –Die Architektur
    Beschreibung der Systemarchitektur aus Anwendersicht, besteht aus - Textueller Beschreibung der einzelnen Komponenten des Systems - UML Verteilungsdiagramm zur Visualisierung der physikalischen Struktur des Systems
  33. Es gibt auch andere Standards –ARIS
    Architektur integrierter Informationssysteme (ARIS)–Industriestandard für die Analyse und den Entwurf betrieblicher Informationssysteme, der die ganzheitliche Betrachtung von Geschäftsprozessen anstrebt.
  34. ARIS Sichten & Beschreibungsebenen
    • Sichten
    • Organisationssicht:Standorte, Einheiten und Stellen sowie Beziehungen
    • Funktionssicht:Ziele, Funktionen zur Erreichung operativer Ziele, Beziehungen
    • Datensicht:dauerhaft zur Erfüllung der Funktionen gespeicherte Daten
    • Leistungssicht:Sach-und Dienstleistungen als Ergebnisse von Prozessen
    • Steuerungssicht:Sonderstellung: dient der Integration der andere Sichten

    • Beschreibungsebenen
    • Fachkonzept
    • Datenverarbeitungskonzept
    • Implementierung
  35. EPK Diagramme
    • Ereignisgesteuerte Prozessketten (ePK): In der Steuerungssicht verwendete Diagramme zur Abbildung des Prozessmodells. Zentraler Bestandteil von SAP-Referenzmodellen und ARIS.
    • Es wechseln sich stets Ereignis und Funktion ab
    • Jedes Ereignis und jede Funktion haben maximal einen Input-und einen Output-Pfeil
  36. Standardsoftware
    Entscheidung, ob das System im Rahmen einer Individualentwicklung selber programmiert wird oder, ob existierende Standardsoftware an die spezifischen Anforderungen des Unternehmens angepasst werden kann.

    Customizing: Anpassung von Standardsoftware an einen konkreten Anwendungsfall

    • Vorteile von Standardsoftware gegenüber Individualentwicklungengeringeres >Entwicklungsrisiko (ca. ein Drittel der >Eigenentwicklungen scheitern)
    • >Häufig bessere Software-Qualität (Fehlerfreiheit, Stabilität)
    • >Meist geringere Kosten, als bei einer Individualentwicklung
    • >Time-To-Market kürzer, da Software sofort verfügbar

    • Nachteile von Standardsoftware gegenüber Individualentwicklungen
    • >Standardsoftware lässt sich oft nicht exakt an die spezifischen Anforderungen des Unternehmens anpassen
    • >Abhängigkeit vom Anbieter (z.B. Konkursgefahr bei Start-ups)
  37. Total Cost of Ownership von IT-Systemen
    Unter Total Cost of Ownership (TCO) versteht man die Gesamtkosten, die sich durch die Anschaffung/Entwicklung sowie den Betrieb eines Informationssystems über die gesamte Nutzungsdauer ergeben.

    • Kostenfaktoren:
    • >Anschaffungs-bzw. Entwicklungskosten
    • >Kosten für Wartung und Pflege
    • >Kosten für Schulung und Support

    • Die TCO sind ein wichtiger Faktor bei der Entscheidung:
    • >zwischen Standardsoftware und Individualentwicklung
    • >zwischen verschiedenen Standardsoftwaresystemen

    Die TCO eines IT-Systems lassen sich mit dem Profil eines Eisbergs vergleichen, d.h. ein Groß-teil ist versteckt bzw. vorher unbekannt
  38. Was ist Software-Architektur?
    • Softwarearchitektur leitet sich aus (nicht-funktionalen) Zielenab
    • >Definition von Modulenund deren Interaktionen
    • >Keine Interna der Module nach außen sichtbar

    • So einfach ist es für uns aber nicht
    • >Wesentlich dynamischer (Komplexität, Evolution)
    • >In der Bauarchitektur gibt es natürliche und anschauliche Unterscheidungen, z.B. zwischen Gebäude-Etage-Zimmer
    • >Bei Software-Architekturen ist alles „Software“, d.h. Ebenen müssen explizit festgelegt werden

    • Aber zum Glück gibt es bereits Expertenwissen
    • >3-Schichten-Architektur
    • >Model-View-Controller (MVC-Prinzip)
    • >Service orientierte Architektur (SOA)
  39. Definition Software-Architektur
    • Eine Softwarearchitektur ist zusammengesetzt aus
    • >Modulenmit bestimmten Eigenschaften/Verhalten
    • >Beziehungenzwischen den Modulen
    • >Beschreibungen der erlaubten/verbotenen Interaktionen
  40. Beispiel: Model-View-Controller-Prinzip
    • Webbasiertes Werkzeug zur Analyse von Verspätungsdaten (entwickelt im Rahmen einer Diplomarbeit)
    • Analyzer, DataManager: Berechnungen, Datenbank-Anbindung
    • Form:Benutzerschnittstelle (Eingabe/Ausgabe)
    • Controller: „Vermittler“ zwischen den verschiedenen Klassen durch Aufruf und Parameter-Übergabe
  41. Welche Architektur ist denn nun die richtige?
    • Kein Architekturstil kann alles, jeder ist ein Kompromiss
    • Prioritäten und Gleichgewicht zwischen unterschiedlichen Anforderungen müssen evaluiert werden
    • Auch Architekturen können iterativ entwickelt/verändert/verfeinert werden
    • Grundsätze müssen früh festgelegt werden –Details später
  42. Analyse vs. Entwurf
    • Die Analyse…hat die großen Strukturen (Architektur) festgelegt
    • geschieht unabhängig von Plattform und Programmiersprache
    • erzeugt eine globale Sicht auf Verhalten

    • Im Entwurf wird daher nun…die Ausrichtung auf eine Plattform und eine Programmiersprache spezifiziert
    • die Funktionsweise der einzelnen Module konkret entworfen
    • Programmieren-im-Großen
  43. Entwurf
    Im Systementwurf wird exakt festgelegt, wie die Funktionen des Systems zu realisieren sind. Alle wichtigen Implementierungsentscheidungen werden getroffen.

    • Grobentwurf
    • Das Gesamtsystem wird in Form von Systemkomponentenspezifiziert
    • Spezifikation der Schnittstellen und des Zusammenspiels von Komponenten

    • Detailentwurf
    • Verfeinerung des Grobentwurfs mit exakter Definition der Softwarebausteine (Klassen, Eigenschaften, Methoden)
    • Algorithmen, Datenstrukturen, Datensichtenwerden präzise beschrieben und dienen als Programmvorgabe für die Phase Implementierung
    • Teilweise automatische Code-Generierung möglich
  44. Implementierung
    • Implementierung bedeutet die Erstellung eines lauffähigen, qualitativ hochwertigen Softwaresystems mit zugehöriger Dokumentation.
    • Spezifikationen der Softwaremodule werden nun in einer Programmiersprache implementiert
    • Integrierte Entwicklungsumgebungen (IDE)Unterstützen den Entwickler bei der Implementierung
    • Beispiele: Eclipse, Microsoft Visual Studio
  45. Algorithmen und Programme
    Ein Algorithmus ist eine endliche Folge von Anweisungen, deren schrittweise Ausführung eine gestellte Aufgabe löst.

    • Spricht an:
    • Aufgabe
    • Anweisungen
    • Schrittweise Ausführung
    • Endliche Folge

    Anders formuliert: Ein Algorithmus ist eine exakte und vollständig beschriebene Vorgehensweise zur Lösung einer Aufgabe

    Ein Programm ist die Umsetzung (Implementierung) eines Algorithmus mit einer konkreten Programmiersprache.
  46. Die Zukunft –Codegenerierung?
    • CASE (Computer AidedSoftware Engineering) Tools erlauben
    • >Modellierung
    • >Reverse-Engineering
    • >Teilweise Codegenerierung

    • Probleme bei der Codegenerierung
    • >Verhaltensdiagramme oft unvollständig
    • >Nur schwer zu standardisieren
    • >Die meisten kommerziellen CASE-Tools bieten nur eine Übersetzung von Klassendiagrammen in Klassen einer bestimmten Programmiersprache

    • Model DrivenArchitecture(MDA)
    • >OMG Initiative zum Model DrivenDevelopment (MDD)
    • >Modelle als Zentrum der Systemerstellung
    • >Code soll vollständig automatisch generiert werden
  47. Implementierung… und testen!
    Unter Testen versteht man das systematische Ausführen eines Programms mit dem Ziel • Fehler zu finden, möglichst vor der Auslieferung und dem produktiven Einsatz • Qualität nachzuweisen, d.h. zu zeigen, dass die Software die Anforderungen erfüllt

    • Testfälle zeigen nur die Abwesenheit der Fehler, für die sie geschrieben wurden
    • Nicht alle möglichen Programmausführungen können geprüft werden
    • Testfälle sollten schon während oder direkt nachder Anforderungsdefinition aufgebaut werden
    • Schwierige Entscheidung: Wann ist Testen zu beenden?…
    • >wenn die Deadline zur Auslieferung ansteht?
    • >nur die kreativsten Leute sollen testen
    • >Eigene Programme niemals ausschließlich selber testen

    Professionelle Projekte verwenden gleich viel Zeit auf das Testen, wie auf das Schreiben des Programmcodes (50/50-Regel)
  48. Auslieferung und Installation
    • Das Anwendersystem wird in die Verantwortung der Fachabteilung und des technischen Systembetreibers (z.B. Rechenzentrum) übergeben
    • Diese Phase kann unterteilt werden in:
    • >Erstellung eines Einführungsplanes
    • >Übergabe der Software inklusive Dokumentation
    • >System-Installation
    • >Datenmigrationaus Alt-System
    • >Personelle und organisatorische Vorbereitung des Systembetriebs
    • >Schulung der Benutzer des Systems
    • Inbetriebnahmedes Systems

    Bereits in einer wesentlich früheren Phase muss mit der Erstellung der Dokumentation sowie der Arbeitsrichtlinien und Schulungs-Maßnahmen begonnen werden
  49. Dokumentation
    • Eine vollständige, zielgruppenspezifische Dokumentation ist entscheidend für die Akzeptanz durch die Benutzer
    • Erleichtert (oder ermöglicht erst) die zukünftige Wartbarkeit und Erweiterbarkeit (vermeidet Softwareruinen)
    • BenutzerhandbücherZielgruppe:Endbenutzer, Anwender, Web-User
    • Funktion:Erlernen der Benutzung des Systems
    • Inhalt:Dokumentation des Systems und der Abläufe für Endbenutzer
    • Form:Manuals, Online-Hilfe als Hypertext

    • Systemdokumentation
    • >Zielgruppe:zukünftige Systementwickler
    • >Funktion:Grundlage für Wartung und Pflege
    • >Inhalt:Beschreibung von Systemarchitektur und Softwarekomponenten 
    • >Form:Manuals, zunehmend Hypertexte, Kommentare im Programmcode

    • Installations-und Administrationsdokumentation
    • >Zielgruppe:Systemadministratoren
    • >Funktion:Erlernen der Administration des Systems
    • >Inhalt:Installationsschritte, Beschreibung regelmäßiger Wartungsaufgaben, Datensicherungen
    • >Form:Manuals, zunehmend Hypertexte
  50. Veröffentlichung
    • Bei webbasierten Systemen, die sich an nicht klar umrissene Anwendergruppen richten, wie z.B. Portale oder E-Shops, wird nach der Veröffentlichung eine systematische Site-Promotion-Kampagne durchgeführt
    • Online-PromotionAuswahl geeigneter, leicht zu merkender Domainnamen
    • Suchmaschinen-Optimierung (SEO)
    • Anzeigen in Suchmaschinen schalten (in den richtigen Kategorien)
    • Optimierung der Web-Seiten (Keywords, Metatags), um möglichst gute Platzierungen in den Suchmaschinen zu erreichen 
    • Verlinkungen der Site von thematisch verwandten Angeboten aus

    • Offline-PromotionURL auf allen Print-Erzeugnissen (Visitenkarten, Briefpapier, Pressemitteilungen)
    • Klassische Print-/TV-Werbekampagne
  51. Wartung
    • Wartung
    • >Fortlaufende Fehlerbeseitigung

    • Pflege
    • >Modifikation des Systems z.B. wegenÄnderungen der operativen Prozesse, neuer Anforderungen, Gesetzesänderungen, neuer Systemplattform 

    • Risiko-und Sicherheitsmanagement
    • >Einspielen sicherheitskritischer Software-Updates
    • >Regelmäßige Datensicherung

    • Kapazitätsmanagement
    • >Aufstockung der Hardware bei gestiegenen Benutzerzahlen

    • Ausfallsmanagement
    • >Planung von Notfallmaßnahmen für den Fall eines Systemausfalls
  52. Das Schätzproblem der Wirtschaftsinformatik
    • Das Schätzen von Aufwandsgrößen bei langfristigen komplexen Projekten ist a priori oft nur schwer umzusetzen
    • Regel 1:Trenne die Preiskalkulation von der Schätzung von Aufwandsgrößen
    • Regel 2: Schätze nie Gesamtgrößen, sondern zerlege das Projekt in Komponenten und Prozesse und schätze den Aufwand getrennt für diese Teile
    • Regel 3:Trenne die Durchlaufzeit vom erforderlichen Arbeitsaufwand
    • Regel 4:Schätze immer konkrete Größen
    • Regel 5:Bei vernetzten Arbeiten steigt die Projektdauer mit zunehmender Mitarbeiterzahl durch den erforderlichen Koordinationsaufwand
  53. Vor und Nachteile beim Wasserfallsmodell
    • Klarer Ablauf, Prozess beinhaltet in sich abgeschlossene Stufen
    • Leicht identifizierbare Meilensteineund Auslieferung
    • −Unflexibelbei sich ändernden Anforderungen
    • −Inkonsistente Anforderungen werden mitunter erst bei der Implementierung erkannt
    • −Tests werden erst sehr spät durchgeführt
    • −Der Kunde bekommt das Produkt erst bei der Auslieferung zu sehen

    Alle Anforderungen müssen vor der Ausarbeitung des Systems feststehen und werden anschließend „eingefroren“. Spätere Änderungen führen systematisch zu zusätzlichen Prozessen, die viel Zeit und hohe Kosten in Anspruch nehmen können.
  54. Motivation für Extreme Programming
    • Anpassung an natürliche Gegebenheiten im Software-EntwicklungsprozessÄnderungenmüssen zugelassen werden und organisatorisch umsetzbar bleiben
    • Anforderungenkönnen oft erst durch den Einsatz von Prototypen geklärt werden

    Frühe Verfügbarkeit der Grundfunktionalitätist oft entscheidendFunktionen mit zeitintensivem Entwicklungsaufwand und niedrigem Nutzen können iterativ hinzugefügt werden (80:20 Regel)

    Extreme Programming (XP) ist ein Vorgehen, welches insbesondere für kleine Teams sinnvoll ist, wenn die Anforderungen vage sind oder sich schnell ändern können. Ein Hauptziel ist, dass Änderungskosten gering gehalten werden.
  55. Extreme Programming(XP)
    • Starker Fokus auf der Implementierunganstelle einer vorherigen Planung
    • Kleine Entwicklungsteams und häufige Iterationen sollen die Aufgaben klein und überschaubar halten
    • Reaktion auf den immer komplexer werdenden Managementprozessesin Entwicklungsprojekten
    • Der einfachste Entwurf, der alle Testfälle besteht, wird implementiert
  56. Pair Programming
    • Kein Wissensmonopol
    • • Know-how einzelner Funktionalitäten liegt nicht bei einzelnen Entwicklern
    • • Ausscheiden eines Mitarbeiters kann besser aufgefangen werden
    • • Wissen verbreitet sich im Team
    • • „Abgreifen“ von externem Expertenwissen
    • • „Ist ein Programmierer im Urlaub, dann ist auch sein Code im Urlaub.“


    • Effizienz
    • •Bessere Qualität(gemessen an Anzahl bestandener Testfälle)•Weniger Zeitaufwand
    • •Weniger Lines-of-Code
    • •Größere Zufriedenheitder Mitarbeiter
    • •Konzentrationauf das Wesentliche (kein Surfen während der Arbeitszeit
  57. Test DrivenDevelopment
    • Szenarien werden als Testfälle vor der Implementierung festgelegt
    • Integration: nicht die neue Funktionalität testen, sondern das Gesamtsystem
    • Grundregel: je nach Komplexität gibt es pro Funktionalität ein bis zehn Tests
    • Module und Funktionen werden nur hinzugefügt, wenn alle Testfälle bestanden werden
  58. Kundeneinbindung und Releases
    • Zu Beginn des Projekts werden die Anforderungen mit dem Kunden in Form von User Stories festgelegt
    • >Periodisierung ermöglicht dem Entwicklungsteam die Unterscheidung zwischen Grundfunktionen und zusätzlichen (möglicherweise optionalen) Features
    • >Alle Situationen (auch Abläufe im Falle von Fehlfunktionen) werden ebenfalls durch Stories beschrieben
    • >Storyboarding

    • 1. „Der Benutzer wirft Geld in den Automaten ein.“
    • 2. „Sobald der RFID-Chip (MensaCard) an den Kartenleser gehalten wird, wird der Betrag dem der Kartennummer entsprechenden Konto hinzuaddiert.“
    • 3. „Wird die Karte nicht 10 Sekunden lang an den Kartenleser gehalten, bricht Vorgang 2 ab.“

    Der Projektfortschritt wird in der Anzahl erfolgreich umgesetzter User-Stories angegeben

    Der Kunde kann anhand kleinerer Release-Zyklenzeitig eingreifen, wenn die entwickelte Funktionalität nicht seinen Wünschen entspricht
  59. Vor und Nachteile von XP
    • Flexibilitätbei sich ändernden Anforderungen wird gewahrt
    • Dynamische Vorgehensweise mit wenig Overhead für das Prozess-Management
    • Offene Kommunikation über Fehler und Ängste
    • Ungeeignet, wenn es auf beweisbare Programmeigenschaften ankommt
    • Komplettpaket, wobei für einzelne Methoden die Voraussetzungen nicht passen können
    • Agiles Vorgehen wird noch zu oft als Allheilmittel angesehen, sobald eine Entwicklung problematisch wird
  60. Laufen agile Projekte grundsätzlich „besser“?
    • Grundproblemder Software-Entwicklung ist auch in agilen Projekten dasselbe
    • Wenn agile Projekte scheitern, dann aus denselben Gründen wie wasserfallbasierte Projekte
    • Agile Methoden werden oft als Zwischenschritt
    • hin zu zukünftigen Weiterentwicklungen gesehen
    • (z.B. Craftmenship)

What would you like to do?

Home > Flashcards > Print Preview