Please enable JavaScript.

Coggle requires JavaScript to display documents.

Besondere Aktivitäten der Entwicklungsphase - Coggle Diagram

- - - - mehrere Personen oder Personengruppen involviert
      - keine einzelne, abgeschlossene Aktivität zu Beginn des Projektes ⇨ erfolgt in mehreren Zyklen (Iterationen)
  - - - Identifikation der Anforderungen an das System
      - Anforderungen erkennen und im erforderlichen Detaillierungsgrad verstanden werden
      - systematische Ermittlung von Anforderungen
        
        Systemkontext bestimmen: welche Stakeholder und andere Systeme haben direkte Abhängigkeiten zum System
        
        Quellen für Anforderungen ermitteln: Stakeholder, Dokumente, andere Systeme (Altsysteme, Konkurrenzsysteme)
        
        Geeignete Ermittlungstechniken auswählen: Befragung, Beobachtung, GUI-Prototypen)
        
        Anforderungen unter Einsatz der Techniken ermitteln
    - - aktueller Erkenntnisstand für alle Stakeholder sichern, Überblick für alle
      - oft grafische Modelle (Softwaremodelle) als Ergänzung zur Textform
      - Dokumentationsform von Art der Anforderung, vom Zeck und vom Personenkreis für die sie bestimmt ist und von Vorschriften und Vereinbarungen abhängig
      - systematische Dokumentation
        
        Zweck und Zielgruppe bestimmen
        
        Detailebene und Darstellungsart auswählen (z.B. Text, Grafiken, Sotwaremodelle, Prototypen)
        
        Anforderungen dokumentieren
        
        Prüfen: Passt Dokumentation zu Zweck und Zielgruppe ⇨ kritische Reflektion
    - - Ziel: Qualität der Menge der dokumentierten Anforderung nach Kriterien Inhalt, Dokumentation udn Abgestimmtheit sicherstellen
      - Missverständnisse vermeiden
      - Konflikte oder Widersprüche identifizieren ⇨ unter Einbeziehung der Stakeholder auflösen
      - systematisches Prüfen und Abstimmen
        
        Prüfkriterien festlegen: Fokus der Prüfung wird bestimmt
        
        Prüfprinzipien und Prüftechniken auswählen (Review, Walkthrough, Erstellung von Softwareartefakten)
        
        Prüfung durchführen und Ergebnisse dokumentieren: nur Ergebnisse dokumentieren
        
        Abstimmen der Anforderungen/Konfliktmanagement
- - - - Geschäftsobjekte, die im System verarbeitet werden und deren Beziehung untereinander
      - z.B. Schadensmeldung, Versicherungsantrag, Kundendaten
    - - fachliche Beschreibung der Aufgaben des Systems bzw. der spezifizierten Komponente
      - z.B. Algorithmus zur Prämienberechnung, Vorgehen bei Vertragskündigung, Abschluss eines Vertrags
    - - Regelen zu einem Geschäftsobjekt, die nicht verletzt werden dürfen
      - z.B. Datum des Vertragsbeginns muss vor Vertragsende liegen
    - - Zweck der Schnittstelle auf fachlicher Ebene, z.B. Übertragung der Fonds-Kurse in Fondsverwaltung
      - technisches Protokoll/Regeln, nach denen das System mit Umfeld kommuniziert. z.B. HTTP, FTP
      - bei Schnittstelle zu Systemen: Datenstruktur der Nachrichten die ausgetauscht werden, z.B. CSV, XML
      - Schnittstelle zu Anwendern: Aufbau und Verhalten der Benutzeroberfläche
    - - prüfbar machen durch messbare Metriken
    - - technische und organisatorische Randbedingungen, die vom System eingehalten werden müssen z.B. Verweise auf Richtlinien, Standards, Gesetze und Styleguides
  - - - Detaillierte Vorgabe zu Art, Größe, Position, Farbe und Inhalt von Elementen einer Bildschirmseite
      - z.B. Eingabefelder, Texte, Schaltflächen
    - - Spezifikation der Regeln, um Eingabefelder auf fachliche Plausibilität zu prüfen
    - - Spezifikation der Führung des Anwenders durch die Oberfläche in Abhängigkeit von eingegebenen Daten und Aktionen des Anwenders
    - - Skizzen
      - Screenshots von GUI-Prototypen
      - einfache Diagramme, welche Reihenfolge von Dialogmasken darstellen
  - - - komplexe Softwaresysteme werden in Komponenten aufgeteilt, jede Komponente ist unabhängige Softwareinheit
      - Aufgaben
        
        fachl. Komponenten identifizieren und gegenüber anderen Komponenten abgrenzen (z.B. Warenkorb, Artikel, Kunde)
        
        interne Funktionen von Komponenten spezifizieren (z.B. Berechnung der Gesamtsumme)
        
        Abläufe und logische Struktur der ausgetauschten Nachrichten an Schnittstellen spezifizeren
    - - fachliche Entitäten und deren Zusammenhänge
      - mit hilfe von Softwaremodellen werden Aufbau, Zusammensetzung und Beziehungen zwischen versch. fachlichen Entitäten spezifiziert
      - Gewährleistung, dass eingegebene Daten mit Datenmodell übereinstimmen, die in Datenbank gespeichert werden
    - - Aussage, die einen fachlichen Aspekt definiert oder bedingt
      - mit Geschätsregelen können Struktur von Geschäftsobjekten beschireben und Verhalten von GEschäftsprozessen beeinflusst werden
      - Arten von Vorgaben
        
        strukturell: z.B. Vertrag muss immer einem Versicherungsnehmer zugordnet sein
        
        operativ: Schaden über 500.000 muss immer durch zwei Sachbearbeiter begutachtet werden
      - i.d.R. in Form von Text sepzifiziert
- - - - fachliche Anforderungen, Interessen der Stakeholder, erste Aufwandseinschätzung, Menge der Anforderungen dokumentieren und von Stakeholder angenommen werden
    - - Entwurfsentschiedungen zur Erfüllung der Anforderungen ⇨ erste Version der Architekturbeschreibung
      - Entscheidungen überprüfen und bewerten, ggfs . Architektur überarbeitet
    - - getroffene Entscheidungen müssen dokumentiert werden
      - je detaillierter die Entscheidungen, desto technischer und präziser die Dokumentation
      - iterativ
  - - - Skizzen, PowerPointGrafiken ⇨ schnell angefertigt, jedoch ohne festgelegte Semantik und gefährlich großer Interpretationsspielraum
      - strukturierte Softwaremodelle (z.B. UML) ⇨ Notationselemente haben festgelegte Bedeutung (Semantik) und sind weltweit verbreitet
      - spezifische Architekturbeschreibungssprachen (ADL), die in Forschung zu Softwarearchitekturen eingesetzt werden ⇨ oft für praktische Zwecke nicht geeignet
      - Programmcode ⇨ immer aktuell und konsistent zum erzeugten Programmcode ⇨ kein einfacher Überblick und nur von Experten lesbar
    - - Divergenz der dokumentierten Design-Entscheidungen in Form der Architekturbeschreibung und der tatsächlichen Systemarchitektur
      - Softwareentwickler sind weder physikalisch noch logisch an Vorgaben des Architekten gebunden
  - - - Erstellung vor der Umsetzung des Systems auf Grundlage von Designaktivitäten und -Entscheidungen
      - Architekturdokumentation: Vereinbarungen über Gestaltung des Systems explizieren und dokumentieren, legt Rahmen für eigenständige Entscheidungen des Entwicklerteams fest
      - Soll-Zustand der Softwarearchitektur
      - Ausgangspunkt für Validierung der Eignung einer Architektur zur Unterstützung geforferter Qualitätseigenschaften und Randbedingungen
    - - Erstellung der Beschreibung nach der Umsetzung des Systems auf Grundlage des implementierten Programmcodes
      - Zweck: Darstellen und Dokumentieren der tatsächlich implementierten Architektur
      - Ist-Zustand der Softwarearchitektur
      - Nutzung für Vergleich der geplanten und implementierten Architektur oder als Ausgangspunkt für Architekturbewertung hinsichtlich Einhaltung von Normen, Richtlinien oder Gesetzen
  - - - Prozess der Gestaltung von Softwaresystemen aller Art
      - Titel einer IT-Architekturtypologie z.B. Client-Server-Architektur
      - Berufsfeld des IT-Architekten also Fachgebiet IT-Architektur
      - Ergebnis, also Menge der Artefakte, die IT-Architekt erzeugt
      - Bezeichnung für Wissenschaft vom Gestalten von IT-Systemen, Lehre der IT-Architektur
- - - - Unterstützung für zukünftige Systemplattform gesichert?
      - Qualität von Tutorials, HowTos und Experten?
      - Erfahrungen im Einsatz?
      - Frameworks und Bibliotheken vorhanden?
      - Ist Wissen über den ganzen Zyklus verfügbar?
      - Welche Technologien/Sprachen sind Anwendungen umgesetzt mit denen integriert wird?
      - Eingliederung in Anwendungslandschaft
      - Welche Sprache wird beherrscht?
      - Welche Ausführungsumgebung?
    - - Softwarearchitekt entscheidet, welche Programmiersprache
      - z.B. HTML und JavaScript für interaktive Oberflächen, Java für Geschäftslogik, SQL zum Lesen und Speichern von Daten in der Datenbank und XMl für Nachrichtenaustausch mit anderen Systemen
    - - HTM, XML, CSS für Aufbau und Inhalt von Anwendungsoberflächen oder Nachrichten
    - - auch oft in Kombination mit Java oder C# um interaktive Benutzerdialoge zu ermöglichen
      - Java-Script
    - - COBOL, Fortran (heute noch für IT-Systeme von Finanzdienstleistern wie Banken, Versicherungen und Krankenkassen
    - - Java, C#, C++ (v.a. für Informationssysteme)
    - - Java (Android)
      - Objective-C (iOS)
  - - - Erzeugen einer lauffähigen Version aus dem Programmcode (Kompilieren): Build-Systeme (Zusammenstellen, Kompilieren und Testen von in Entwicklung befindlicher Software
      - Unterstützung der Versionsverwaltung: immer aktuelle Version für jeden Entwickler, kein Überschreiben und Löschen, bzw. Wiederherstellung der aktuellen Version ⇨ z.B. Subversion, GitHub, Microsoft Team Foundation Server
      - Generierung von Programmcode für triviale Aufgaben (z.B. mit grafischem GUI-Editor)
      - Einbindung von Bibliotheken und Framework (z.B. durch Import- und Navigationsfunktionen)
      - Unterstützung des Schreibens von Programmcode (z.B. Syntax-Highlighting, Kompilierfehler erkennen, automatische Vervollständigung, Navigation durch Programmcode, Ausführen des Programmes zu Testzwecken)
  - - - Programmcode automatisch generieren
        
        sinnvoll, wenn Aufwand zur erstellung und Wartung des Code-Generators geringer als für manuelle Erzeugung
        
        Erzeugung von Programmcode für Benutzerschnittstellen aus grafischen Editoren (z.B. Microsoft Visual Studio, XCode)
        
        aus modellierten Datenstrukturen kann Programmcode zur Anbindung an Datenbanksysteme direkt aus Modell erzeugt werden
        
        automatische Generierung von Code aus Elementen der Architekturbeschreibung
      - Wiederverwendung von bestehendem Programmcode
        
        Fertigkeiten von Entwicklern: Schreiben von Programmcode, Wissen, welches Framework welche Fuktion zur Verfügung stellt und wie sie integriert werden können
        
        bestehende Lösungen zu allgemeinen Problemen werden in Frameworks (Bibliotheken) den Entwicklern zur Verfügung gestellt
        
        Standardprobleme heute durch fast jede Programmiersprache unterstützt
        
        zurückgreifen auf bereits programmierte Lösungen des Problems
      - Schreiben von Programmcode
        
        Erstellung von strukturiertem Text zur gezielten Lösung von spezifischen Problemen (Datenstruktur, Algorithmus implementieren, Regeln zur verarbeitung von Daten)
    - - ausführbare Version, die auf Rechner gestartet werden kann ⇨ kompilierte Binärversion
      - Menge der vom Entwicklungsteam erzeugte bzw, zusammengestelle Artefakte ⇨ Quellcode
  - - - Gesamtverantortung, Verantwortung über einzelne Komponenten, Verantwortung über einzelne Schnittstellen