HallerWiki - User contributions [en]

FS

2019-08-04T11:52:10Z

Christian: Created page with "== Produktion == [http://pww.post.ch/appl/oe/it/invq/wpl/index.aspx InvQ] [http://pww.post.ch/appl/oe/it/logistictool/wpl/ LP-Tool] [http://fs.pnet.ch/appl/net/ FS/net] [ht..."

== Produktion ==

[http://pww.post.ch/appl/oe/it/invq/wpl/index.aspx InvQ]

[http://pww.post.ch/appl/oe/it/logistictool/wpl/ LP-Tool]

[http://fs.pnet.ch/appl/net/ FS/net]
[http://pwwint.post.ch/appl/oe/it/invq/wpl/index.aspx InvQ]

[http://pwwint.post.ch/appl/oe/it/logistictool/wpl/ LP-Tool]

[http://fs.pnet.ch/appl-int/net/ FS/net]

== JIRA ==
[https://jira.pnet.ch/browse/FSNET/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel JIRA FSApp]

[https://jira.pnet.ch/browse/LPTOOL/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel JIRA LP-Tool]

== Integration ==

[https://jira.pnet.ch/browse/FSTLS/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel JIRA FS Tools]

[https://jira.pnet.ch/browse/INVQ/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel JIRA Inventartools]

== WIKI ==

[https://wikit.pnet.ch/display/FSAP/FS-App+Home WIKI FSApp]

[https://wikit.pnet.ch/display/OUIT33/01-LP-Tool WIKI LP-Tool]

[https://wikit.pnet.ch/pages/viewpage.action?pageId=105122786 WIKI InvQ]

[https://wikit.pnet.ch/pages/viewpage.action?pageId=218104243 WIKI FS/net]

== Diverses ==

[http://elearningint/fsapp/v05_fr/story.html WBT FSApp Franz]

[http://elearningint/fsapp/v05/story.html WBT FSApp Deutsch]

== Valuemation ==

[https://valuemation.post.ch/vm https://valuemation.post.ch/vm]

[https://valuemation.post.ch/mobile https://valuemation.post.ch/mobile]

[https://usu-vm-prod1.pnet.ch:7000/vm/vmweb https://usu-vm-prod1.pnet.ch:7000/vm/vmweb]

[https://usu-vm-prod2.pnet.ch:7000/vm/vmweb https://usu-vm-prod2.pnet.ch:7000/vm/vmweb]

[https://usu-vm-prod1.pnet.ch:7000/mobile https://usu-vm-prod1.pnet.ch:7000/mobile]

[https://usu-vm-prod2.pnet.ch:7000/mobile https://usu-vm-prod2.pnet.ch:7000/mobile]

[https://valuemation-test.post.ch/mobile https://valuemation-test.post.ch/mobile]

[https://valuemation-test.post.ch/vm/vmweb https://valuemation-test.post.ch/vm/vmweb]

[http://usu-vm-test1.pnet.ch:7000/mobile http://usu-vm-test1.pnet.ch:7000/mobile]

[http://usu-vm-test2.pnet.ch:7000/mobile http://usu-vm-test2.pnet.ch:7000/mobile]

[http://usu-vm-test1.pnet.ch:7000/vm/vmweb http://usu-vm-test1.pnet.ch:7000/vm/vmweb]

[http://usu-vm-test2.pnet.ch:7000/vm/vmweb http://usu-vm-test2.pnet.ch:7000/vm/vmweb]

[https://valuemation.post.ch/knowledgecenter https://valuemation.post.ch/knowledgecenter]

[https://valuemation.post.ch/siweb https://valuemation.post.ch/siweb]

== Learn Links ==

[https://de.wikibooks.org/wiki/Einf%C3%BChrung_in_SQL:_Arbeiten_mit_JOIN SQL Arbeiten mit Join]

[http://stackoverflow.com/questions/7391370/is-it-linq-or-lambda:Linq Lambda Query Syntax Method Syntax]

[https://msdn.microsoft.com/en-us/library/gg509017.aspx:Linq query examples (MSDN)]

[http://ayende.com/blog/1890/nhibernate-cascades-the-different-between-all-all-delete-orphans-and-save-update NHibernate Cascades]

Informatiker FA M249 Zusammenfassung

2019-08-01T13:22:11Z

Christian: Created page with "= IT-Teilprojekt initialisieren = Damit Projekte und Teilprojekte innerhalb des geplanten Zeit- Und Kostenrahmens erfolgreich abgeschlossen werden können, gewinnt die gutgeh..."

= IT-Teilprojekt initialisieren =

Damit Projekte und Teilprojekte innerhalb des geplanten Zeit- Und Kostenrahmens erfolgreich abgeschlossen werden können, gewinnt die gutgeheissen stark an Bedeutung. Eine systematische Initialisierung bringt folgende Vorteile:

*Zwischen Auftraggeber, PL und TPL werden eindeutige Projektziele vereinbart.
*Der Projektauftrag wird von PL bzw. TPL überprüft und einvernehmlich gutgeheissen.
*Die wichtigsten Risiken und Gegenmassnahmen sind bekannt.
*Dies ausgewählten PL bzw. TPL verfügen über eine hohe Methoden- und Sozialkompetenz.
*Das Projekt wird sinnvoll strukturiert.
*Es wird die Basis für eine gezielte Planung, Steuerung, Kontrolle und Kommunikation des Projektes geschaffen.

Die Tätigkeiten bei der Initialisierung eines Teilprojektes lassen sich wie folgt zusammenfassen:
*Auftrag/Ziele definieren.
*Teilprojekt strukturieren
*Teilprojektorganisation aufbauen
*Teilprojektplanung erstellen

Für die Führung und Steuerung des Projektes sind v.a. die Ziele von fundamentaler Bedeutung. Eine systematische Zieldefinition umfasst folgende Schritte:
*Ziele erheben
**Ist-Situation analysieren
**Bedürfnisse der künftigen Benutzer ermitteln
**Vorstellungen der betroffenen Fachabteilungen einholen
**Unternehmensstrategie und -ziele berücksichtigen
**IT-Strategie bzw. Informatikleitbild einbeziehen
**Projektziele und Ziele der anderen Teilprojekte einfordern.
**Anforderungen des QS-Managements aufnehmen
**Gesetzliche Anforderungen beachten
**Verträge konsultieren
*Ziele formulieren. Die mit oben aufgeführten Tätigkeiten erhobenen Ansprüche müssen nun in eindeutige Ziele umformuliert und schriftlich festgehalten werden.
*Ziele analysieren
**handelt es sich um echte Ziele?
**beziehen sich die Ziele wirklich auf das Projekt?
**liegen redundante Ziele vor?
**handelt es sich um Muss-, Soll- oder Kann-Ziele?
**Liegen Zielkonflikte vor?
*Ziele klassifizieren
**Systemziele beziehen sich auf die erwartet Lösung und diene gleichzeitig als Kriterium bei der Beurteilung von Lösungsvorschlägen. In der Praxis werden Systemziele in wirtschaftliche, funktionelle und soziale Ziele untergliedert.
**Vorgehensziele
*Ziele operationalisieren. Dabei werden Ziele so formuliert, dass bekannt ist anhand welchen Massstabes die Zielerreichung beurteilt wird. Als Massstab können quantitative und/oder qualitative Kriterien herangezogen werden.
*Zieldefinition dokumentieren. Die Dokumentation der Zieldefinition hat den Vorteil, das die Entstehungsgeschichte der Ziele schriftliche festgehalten wird und diese somit nachvollzogen werden können. Der Prozess der Zieldefinition kann mit folgern Struktur festgehalten werden:
**Auftrag
**Projektziele
**Ansprüche aller Interessengruppen
**Zielanalyse
**Zielstruktur
*Ziele kommunizieren (zuerst beim Projektstart, danach immer wieder)

Je nach Auftrag kommen verschiedene Vorgehensmodell zum Einsatz. Anhand des Vorgehensmodell werden Projekte strukturiert. Für jede Phase werden die Tätigkeiten festgelegt um die gewünschten Ergebnisse zu erreichen. Betreffend Detaillierungsgrad gilt: Wenn die Aufgaben der untersten Gliederungsebene den am Projekt beteiligten Mitarbeitern als Arbeitsaufträge zugeordnet werden können, ist eine angemessene Strukturierungstiefe erreicht.

Die Strukturierung eines IT-Teilprojektes kann nach folgenden Prinzipien erfolgen:
*Für die Gliederung nach Objekten kommen alle Objekte in Frage die im Rahmen des Projektes "bearbeitet" werden müssen.
*Für die Gliederung nach Funktionen kommen alle Tätigkeiten in Frage die im Rahmen des Projektes verrichtet werden müssen.
*Für die Gliederung nach Projektphasen kommen alle Phasen des Vorgehensmodell in Frage die im Rahmen des Teilprojektes durchlaufen werden müssen.

Die einzelnen Aufgaben bzw. Strukturelement müssen systematisch bezeichnet werden um sie jederzeit in der Strukturhierarchie identifizieren zu können.

Im nächsten schritt werden die nummerierten Aufgaben bzw. Strukturelemente des Projektes beschrieben:

*Allgemeine Informationen: Eindeutige Bezeichnung des Projektes und des Arbeitspakete, Titel des Arbeitspakets, verantwortliche Person, TPL als Auftraggeber, Start des AP, Ende des AP.
*Ziele, Leistungsziele, Qualitätsziele
*Ergebnisse: Beschreibung, Quantität, Qualität, Form der Ergebnisse
*Schnittstellen: zu anderen AP im TP, Schnittstellen zu anderen AP in anderen TP
*Voraussetzungen: finanzielle Ressourcen, zu beachtende Dokumente, weitere Rahmenbedingungen
*Kontrolle: Gesamtaufwand für AP, Gesamtkosten für AP, Termineinhaltung durch den Verantwortlichen, qualitative und quantitative Leistung durch den verantwortlichen
*Anhang: Dokumente, Planung

Nach der Erstellung der Teilprojektstruktur, kann der TPL die daraus abgeleiteten Aufgaben zu Stellen bündeln. Dabei dokumentiert er jede Stelle mit den zugewiesenen Aufgaben, Kompetenzen und Verantwortungen und beschreibt sie nach den Inhalten einer Stellenbeschreibung.
Für die Aufgabenbündelung und Stellenbeschreibung können die aktuellen Berufsbilder der Informatik herbeigezogen werden. (für interne oder externe Rekrutierung). Wenn der TPL weisse welche Stellen benötigt werden kann der die Projektorganisation aufbauen. Die Form wird beeinflusst durch die Organisationsform der Gesamtprojektes anderseits durch die Vor- und Nachteile der möglichen Organisationsformen:
*Reine Projektorganisation
*Matrix-Projektorganisation
*Stabs-Projektorganisation

In einem weiteren Schritt wird das Projektinformationssystem (PIS) entworfen. Dabei werden die Projektbeteiligten und Projektbetroffenen ermittelt. Dann werden geeignete Kommunikationsformen definiert und schliesslich ein konsistenten Berichtswesen konzipiert.

Schliesslich wird abgeklärt welche Sachmittel für die Auftragserfüllung erforderlich sind.

= IT-Teilprojekte planen =

Die Teilprojektplanung soll den Ablauf des TP und die Abhängigkeiten der einzelnen Vorgänge sowie gegenüber den anderen TP transparent machen. Auf diese Weise sollen mögliche Termin- und Personalengpässe und Konflikte mit anderen TP aufgedeckt werden.
Nach der Initialisierung und vor dem Start eines TP wird eine Basisplanung erstelle welche alle Vorgänge vom Anfang bis zum Ende des TP berücksichtigt. danach soll eine laufende Planung sicherstellen, dass auf Planabweichungen sofort reagiert werden kann (Feststellung durch laufende Fortschrittskontrollen)

Der Planungsprozess eines TP setzt sich auf folgenden Schritten und Ergebnissen zusammen:
*Strukturplanung / Strukturplan
*Ablaufplanung / Ablaufplan
*Terminplanung / Terminplan
*Einsatzmittelplanung / Einsatzmittelplan
*Kostenplanung / Kostenplan
*Kommunikationsplanung / Kommunikationsplan

Ziel der Ablaufplanung ist es die Reihenfolge der Vorgänge eines TP sowie ihre Abhängigkeiten zu anderen Vorgängen zu ermitteln. Das Ergebnis der Ablaufplanung, der Ablaufplan, ist seinerseits die Basis für die Terminplanung. Das Zier der Terminplanung besteht darin, die Start- und Endtermine jedes einzelnen Vorganges so wie des gesamten TP zu bestimmen.

Voraussetzung für eine möglichst realistische Terminplanung ist eine sorgfältige Schätzung der Vorgangsdauer. Zu diesem Zweck stehen dem TPL verschieden Schätzverfahren zur Verfügung. Einige davon sind speziell für Softwareentwicklungsprojekte geschaffen worden.

Um die Ablauf- und Terminplanung übersichtlich darzustellen, haben sich in der Praxis die Netzplantechnik und das Balkendiagramm als geeignet erwiesen. Das Balkendiagramm, inklusive Fortschrittsinformation wird sehr oft auch für die Kommunikation gegenüber Kontrollgremien verwendet.

Definition Netzplan aus Wikipedia:

''Die Netzplantechnik verwendet Netzpläne, welche temporale und finale Verkettung von Aktionen beschreiben. Sie findet ihre Anwendung insbesondere in der Terminplanung von Projekten. Eine Netzplanung wendet Konzepte der Graphentheorie an. Meist besteht der Netzplan aus einer planaren Grafik mit Knoten und Kanten als Elementen. Die Kanten sind beim Netzplan gerichtet und nicht zyklisch. Es gibt die beiden grundsätzlichen und dualen Varianten''

Die Einhaltung des Terminplanes hängt stark von der richtigen Wahl der Einsatzmittel ab. Die Einsatzmittelplanung setzt sich aus folgenden Schritten und Ergebnissen zusammen:
*Bedarf ermitteln: Bedarfsübersicht, Stellenbeschreibung, Pflichtenhefte
*Einsatzmittel evaluieren: Verfügbarkeitsübersicht
*Einsatzmittelplan erstellen: Vorgangsliste mit Einsatzmitteln, Personaleinsatzplan

Bei der Bedarfsermittlung wird mittels Arbeitspaketanalyse festgestellt, welche Ressourcen aufgrund der bisherigen Planung (Strukturplanung, Ablauf- und Terminplanung) für das TP benötigt werden. Hierzu wird ermitteln welche Aktivitäten jedes Arbeitspaket umfasst und welche Ergebnisse jedes Arbeitspaket liefern muss. Als Ergebnis werden die erforderlichen Einsatzmittel im Rahmen einer Bedarfsübersicht festgehalten. Besonders bei grösseren TP empfiehlt es sich im Anschluss an die Bedarfsermittlungen Stellenbeschreibungen für die erforderlichen Personalressourcen sowie Pflichtenhefte für die benötigten Sachmittel zu erstellen. Dies erleichtert die Evaluation der Einsatzmittel.

Die Evaluation der Einsatzmittel kann in folgende Aufgaben unterteilt werden:
*Geeignete Mitarbeiter rekrutieren (intern und/oder extern)
*Geeignete Sachmittel auswählen
*Verfügbarkeitsübersicht erstellen

Im Einsatzmittelplan wird festgehalten was wo und zu welchem Zeitpunkt des TP eingesetzt wird (gemäss Kapazitätsgruppen aus Bedarfsübersicht). Die Erstellung des Einsatzmittelplan wird wie folgt gegliedert:
*Personal und Sachmittel den Arbeitspaketen zuordnen. Ergebnis = Vorgangsliste mit den zugeordneten Einsatzmitteln
*Personaleinsatzplan erstellen. Ergebnis: Ressourcen-Belastungsdiagramm

Die Verantwortung und Kompetenz bezügliche Kostenplanung liegt beim PL. Trotzdem kann er bestimmte Aufgaben der Kostenplanung an den TPL delegieren. Oft hat hat dieser die Aufgabe die Kosten seines TP zu berechnen und die tatsächlich angefallenen Kosten zu rapportieren.

Die wichtigste Voraussetzung für eine realistische Kostenplanung ist eine sorgfältig durchgeführte Termin- und Einsatzmittelplanung. Der ermittelte Bedarf an Personal- und Sachmitteln aus der Einsatzmittelplanung kann für die Ermittlung der '''direkten Kosten''' herangezogen werden, wobei die Einsatzmittelarten als Kostenarten betrachtet werden. Können Kosten keinen bestimmten Arbeitspakete zugeordnet werden spricht man von '''indirekten Kosten''' (Gemeinkosten).

Die Vorgehensweise bei der Kostenplanung ist analog zur Einsatzmittelplanung:
*'''Kosten ermitteln''': Zu diesen Zweck wird die bestehende Vorgangsliste aus der Einsatzmittelplanung verwendet und die benötigten Einsatzmittel durch die voraussichtlichen Kosten ersetzt. Die Kosten pro Arbeitspaket werden i.d.R. anhand des geplanten Mengengerüstes berechnet. Dazu wird die geplante Menge mit dem Preis pro Einheit multipliziert und dem entsprechenden Arbeitspaket zugeordnet.
*'''Kostenplan erstellen''': Nachdem die direkten und indirekten Kosten aller Arbeitspakete ermittelt und festgehalten wurden, müssen diese im Kostenplan nach Kostenart und Zeitperiode gegliedert zusammengefasst werden. Je nach TP bzw. nach Bedürfnis des PL können hierbei unterschiedliche Kostenarten und Zeitperioden differenziert werden. Die direkten Kosten werden über alle Arbeitspakete hinweg summiert und in den Kostenplan übertragen. Anschliessen werden die Gemeinkosten hinzuaddiert. Der fertige Kostenplan wird dem PL übergeben.

Vorgehen bei der Kommunikationsplanung:
*Informationsbedürfnis ermitteln (Wer ist an welchen Informationen interessiert? Welche Informationen sollen/dürfen diesen Personen gegeben werden? Deshalb: Aufbauen einer Tabelle welche zeigt welche Gruppe welche Infos erhält)
*Kommunikationsmassnahmen festlegen
*Berichtswesen für das Teilprojekt aufbauen

Festzulegen:
*was wird mündlich kommuniziert?
*was wird schriftliche kommuniziert?
*was ausserhalb des TP?
*was innerhalb des TP?

In einem ideal funktionierenden Berichtswesen gelangen die gewünschten Informationen zum richtigen Zeitpunkt am richtigen Ort an und werden stufengerecht weiterverteilt.

Aufbau des internen Berichtswesen:
*Wies sieht das PIS für das Gesamtprojekt aus?
*Welche Aufgaben muss der TPL im Rahmen des PIS übernehmen?
*in welchem Intervall müssen welche Informationen an wen weitergegeben werden?

Grundsätze für ein PIS:
*Empfänger (Zielgruppen) berücksichtigen
*Zeitpunkt abstimmen
*Inhalt der Berichte festlegen
*Form der Berichte festlegen

Folgende Dokumente sind bei der Ausgestaltung eines internen Berichtswesens hilfreich bzw. notwendig:
*Projektdokumente
*Systemdokumente (können sowohl die zu entwickelnde Lösung als auch das fertige Projektergebnis beschreiben)

= Umgang mit Risiken, Qualitäts- und Änderungsanforderungen =

*Es ist wichtig die Risiken zu identifizieren und Gegenmassnahmen vorzusehen. Mit Risiken sind Verlustgefahren gemeint (z.B. betriebliche Störungen, Fehlinvestitionen, Zahlungsunfähigkeit der Kunden, Absatzschwierigkeiten).
*Teilprojektrisiken sind Verlustgefahren die mit einem bestimmten Teilprojekt verbunden sind.
*Die Risiken zu erkennen, zu bewerten und zu bewältigen ist Aufgabe des Teilprojekt-Risikomanagements.

Das '''Teilprojekt-Risikomanagements''' ist ein fortlaufender Prozess der folgende Tätigkeiten umfasst:

*Risikoanalyse
*Risikovorsorge
*Risikobewältigung
*Risikoüberwachung
*Massnahmenüberwachung

Im Rahmen der Planung und Initialisierung eines IT-Teilprojektes setzt sich der der TPL mit den Prozessen Risikoanalyse und Risikovorsorge auseinander. An der Risikoanalyse sollten möglichst viele am Projket mitarbeitende Personen mitarbeiten. Dies erzeugt von Anfang an ein hohes Risikobewusstsein. Auf keinen Fall sollte der TPL die Analyse alleine vornehmen. Nach Möglichkeit sollten folgende Personen beteiligt sein:

*PL
*TPL
*andere direkt betroffenen TPL
*Projektbetroffene oder beteiligte mit Erfahrung in der Risikoanalyse
*Querdenker

Die Risikoanalyse kann im Rahmen eines Workshop durchgeführt werden. Das Ergebnis ist eine teilprojektspezifische Risikotabelle der Projektrisiken.

Für die Risikoidentifikation eignen sich folgende Techniken:
*anhand Risikokategorien identifizieren.
*anhand CL identifizieren.
*anhand kritischer Erfolgsfaktoren (KEF) identifizieren.
*anhand externer Einflussgrössen identifizieren.
*anhand des Ablaufplanes für das TP identifizieren.

Informatiker FA M197 Zusammenfassung

2019-08-01T13:21:40Z

Christian: Created page with "= Einführung in das Konfigurationsmanagement = *Stellt sicher, dass die Informationen über die Konfiguration von Hard- und Software aktuell und korrekt sind. *Dazu werden v..."

= Einführung in das Konfigurationsmanagement =
*Stellt sicher, dass die Informationen über die Konfiguration von Hard- und Software aktuell und korrekt sind.
*Dazu werden verschiedene Methoden und Tools eingesetzt
*Hat eine zentrale Bedeutung für die Bereitstellung von Informationen für Service-Management-Prozesse
*Ziel und Nutzen liegen darin die Verfügbarkeit der Systeme zu gewährleisten indem Änderungen bewusst geplant und nachvollziehbar durchgeführt werden.
*Bei einem Fehlverhalten nach der Änderung kann der alte Zustand wiederhergestellt werden.
*Man weiss jederzeit woraus die IT-Systeme bestehen und welche Hard- und Software im Einsatz ist.
*Konfigurationsmanagement ist Teil der operationellen Ebene des IT-Service-Managements nach ITIL (IT Infrastructure Library)

Es bestehen Schnittstellen zu den folgenden Services:
*Changemanagement
*Störungsmanagement
*Problemmanagement
*Softwarekonrolle und -verteilung

= Wichtige Elemente und Aspekte des Konfigurationsmanagement =

*zentrales Element sind die '''Konfigurationseinheiten''' (kleinste auswechselbare Einheit einer Konfiguration)
*Die Konfigurationseinheiten lassen sich in folgende Typen unterteilen
**Hardware (z.B. Harddisk)
**Software (z.B. Datei)
**Dokumentation (z.B. einzelnes Dokument)

Je nach Anforderung des Unternehmens werden mehr oder weniger detaillierter Informationen erhoben. Bei der Software unterscheidet man zudem zwischen Varianten und Versionen.

*'''Versionen''' haben unterschiedliche Funktionen.
*'''Varianten''' haben die gleichen Funktionen, laufen aber z.B. auf einem anderen OS (Windows, Unix)

Zu den einzelnen Konfigurationseinheiten werden verschiedene '''Attribute''' erfasst damit diese genau identifiziert werden können. Eines dieser Attribute ist der '''Status'''.

Die Informationen zu den einzelnen Konfigurationseinheiten werden in der Konfigurationsmanagement-Datenbank (CMDB) abgelegt. Bei Software und Dokumentation können zudem die Konfigurationseinheiten selber in der DB abgelegt werden. Im Falle der Software spricht man dabei von der Definitive Software Library (DSL)

'''Hauptaufgabe''' des Konfigurationsmanagements ist die '''Kontrolle über die einzelnen Konfigurationseinheiten''' und deren Status. Darüber hinaus unterstützt es das '''Changemanagement''' und die Softwareentwicklung.

Die Verantwortung des Konfigurationsmanagements liegt vor allem beim '''Konfigurationsmanager'''. Dieser stellt den Konfigurationsmanagement-Prozess sicher. Eine weitere wichtige Funktion hat der Change-Manager. Er muss dafür sorgen, dass bei Änderungen die '''Konfigurationsdatenbank''' aktualisiert wird.

Der Konfigurationsmanagement-Prozess besteht aus folgenden Funktionen
*Identifikation der Konfigurationseinheiten
*Kontrolle der Integrität der Konfigurationseinheiten
*Überwachung des Status der Konfigurationseinheiten
*Plausibilisierung der Daten

= Konfigurationsmanagement und Change Management =

Das Ziel des Change-Management-Prozess ist die wirtschaftliche und termingerechte Durchführung von Änderungen. Dabei sollen möglichst keine Risiken eingegangen werden.

'''Nutzen''':
*kontrollierte Änderungen und somit weniger durch Änderungen verursachte Qualitätseinbussen
*frühzeitige Risikoerkennung
*weniger fehlerhafte Änderungen
*wertvolle Managementinformationen über geplante und durchgeführte Änderungen und deren Wirkung.
*stabilere Anwendungen und dadurch höhere Anwenderproduktivität
*bessere Produktivität der Informatik-Spezialisten
*besseres Überstehen von Zeiten mit hohem Aufkommen von Änderungen
*Sicherstellung, dass bei Problemen der ursprüngliche Zustand wiederhergestellt werden kann.

Bevor eine Änderung durchgeführt wird, muss der Änderungsantrag registriert und geprüft werden. Danach werden die Auswirkungen auf andere Konfigurationseinheiten und Services analysiert sowie die Dringlichkeit festgesetzt. Erst wenn die Auswirkungen bekannt sind, kann die Änderung freigegeben werden.
Im Change Management wird auch noch überwacht, ob die Änderung korrekt durchgeführt und ob das erwartete Resultat erreicht wurde. Sonst Rollback.

= Konfigurationsmanagement planen =
*Vor der Einführung muss man sich über die Anforderungen und Erwartungen im Klaren sein.
*Weil es sich meistens um ein Infrastrukturprojekt von grösserer Bedeutung handelt, muss unbedingt systematisch vorgegangen werden.
*Es gilt das Konfigurationsmanagement in die bestehende Infrastruktur einzubinden und gleichzeitig offen für zukünftige Erweiterungen/Anpassungen zu sein.
*bedingt ein phasenweises, strukturiertes Vorgehen

Da es eine Vielzahl von professionellen Lösungen gibt, dürfte eine Eigenentwicklung nicht in Frage kommen. Die meisten Konfigurationsmanagement-Projekte sind deshalb Evaluationsprojekte.
*Pflichtenheft erstellen
*Anhand Nutzwertanalyse werden Anbieter und deren Produkte verglichen

= Konfigurationsmanagement implementieren =

*Das Anlegen der Konfigurationsmanagement-Datenbank und der Definitive Software Library (DSL) sind die aufwändigsten Arbeiten.
*Ohne Toolunterstützung ist dies in einer grossen Umgebung nicht zu schaffen.
*Die automatisch erfassten Daten müssen jedoch meistens noch überarbeitet werden.
*Die Arbeitsprozesse müssen umgestellt werden (Neue Weisungen erlassen)
*Ausbildung der Mitarbeiter

Nach erfolgter Implementation muss geprüft werden ob die Ziele des Konfigurationsmanagements erreicht werden. Dazu sollten folgende Informationen vorliegen:

*Anzahl Fehlern in der CMDB durch ein fehlerhaftes Konfigurationsmanagement
*Aktualität des Systems
*Anzahl der nicht registrierten Konfigurationseinheiten.
*Service-level-Abweichungen durch fehlerhaftes Konfigurationsmanagement
*Anzahl der Fehler und Störungen die Einfluss auf das Konfigurationsmanagement haben.
*Anzahl der Softwarefehler die durch ein fehlerhaftes Konfigurationsmanagement verursacht werden.
*Anzahl der durch das Konfigurationsmanagment verursachten Engpässe und Verzögerungen
*Inhalt und Regelmässigkeit der Berichterstattung
*Potenzial der CMDB für Trendanalysen
*Qualität der Zukunftsstrategie des Konfigurationsmanagement

Ziel ist die ständige Verbesserung des Konfigurationsmanagements. Hierzu sollten Vorschläge gemacht und Verbesserungsmassnahmen eingeleitet werden.

Informatiker FA M168 Zusammenfassung

2019-08-01T13:21:08Z

Christian: Created page with "== Einleitung == Ein Unternehmen kann ab einer bestimmten Grösse nicht ohne organisatorische Regelungen funktionieren. Es ist Aufgabe des '''Organisators''' solche Regelunge..."

== Einleitung ==

Ein Unternehmen kann ab einer bestimmten Grösse nicht ohne organisatorische Regelungen funktionieren. Es ist Aufgabe des '''Organisators''' solche Regelungen zu schaffen und das Unternehmen zu gestalten. Dazu stehen ihm bewährte '''Methoden''' und '''Techniken''' zur Verfügung.

Die Organisation eines Unternehmen lässt sich durch wenige Aspekte beschreiben und bildlich darstellen (Organisationswürfel)

[[Image:Organisationswürfel.jpg|Organisationswürfel]]

== 1 Grundlagen der Organisation ==

Organisation ist immer mit der Einführung von organisatorischen regelungen verbunden. Dabei sind die Vor- und Nachteile der Regelungen gegeneinander abzuwägen. Damit das Unternehmen sowohl stabil funktioniert als auch flexibel agieren kann, ist der richtige '''Organisationsgrad''' zu wählen

=== 1.1 Organisatorische Regelung ===

Es braucht eine übersichtliche Organisationsstruktur(Aufbauorganisation) und eine sinnvolle Planung der Arbeitsabläufe (Ablauforganisation).

Aufgaben des Organisators:
*Organisationsprobleme analysieren und lösen
*Organisationsstruktur analysieren bzw. entwerfen
*Im Rahmen des Organisationsprojektes Verantwortliche festlegen
*Geeigne Techniken und Werkzeuge einsetzen
*Betroffene Menschen an der Problemlösung beteiligen.

Organisatorische Regelungen haben folgende Vor- und Nachteile

Beispiel:

{| border="1"
! Vorteile !! Nachteile
|-
| Grössere Stabilität || verringerte Flexibilität
|-
| Erhöhung der Transparenz || Gleichbehandlung von Sonderfällen
|-
| Eindeutigkeit der Zuständigkeiten || Gefahr von Dienst nach Vorschrift
|-
| Verbesserte Koordination || Verlust an Motivation
|-
| Verringerung personeller Abhängigkeiten || Bürokratie
|-
| Verringerung des Planungsaufwands ||
|}

=== 1.2 Ausprägungsformen einer Organisation ===

je nach Unternehmensgrösse und Unternehmenszweck ist die Organisation verschieden ausgeprägt.

*Organisationsgrad hoch:organisiert. Viele stark verankerte Regelungen sind vorhanden und werden täglich angewendet. Neben den vielen Vorteilen gibt es folgende Nachteil: kann weniger flexibel auf Änderungen reagieren. Beiepiel für Unternehmen mit hohem Organisationsgrad: Verwaltungen, Banken, Versicherungen.
*Organisationsgrad mittel: improvisiert. Regelungen mit vorläufigem oder zeitlich befristeten Charakter werden als Improvisation bezeichnet. Solche Lösungen sind dynamisch und das Unternehmen hat einen grossen Spielraum für Ad-hoc-Entscheidungen. Beispiel für solche Unternehmen: KMU.
*Organisationsgrad tief: dispositiv. Eine Disposition beinhaltet Regelungen für den Einzelfall. Die einzelnen Personen haben mehr Handlungsspielraum. Die Ausgestaltung eines Arbeitsschrittes ist teilweise dem Mitarbeiter überlassen (sein Dispositionsspielraum). Beispiele für solche Unternehmen: Einzelfirmen, Startups.

Formale und informale Organisation

*Formale Beziehungen sind solche die durch offizielle Regelungen festgelegt worden und dokumentiert sind.
*Informale Beziehungen entwickeln sich von selbst und sind Teil der Unternehmenskultur. Sie bleiben oft unausgesprochen und deneke sehr wirksam und möglicherweise höchst effizient (z.B. informale Kommunikationswege)

Es wird angenommen, dass der Anteil der dokumentierten formalen Organisation gegenüber der informalen Organisation nur etwa einen Drittel ausmacht.
Wenn ein Unternehmen Konflikte lösen oder weiter entwickelt werden muss, müssen dir informalen Beziehungen aufgedeckt werden.

== 2 Gestaltungsaspekte der Organisation ==

=== 2.1 Organisationswürfel ===

Grundlegende Elemente der Organisation sind: Aufgaben, Aufgabenträger, Sachmittel und Informationen.

Die Aufbauorganisation regelt Zuständigkeiten und Verantwortlichkeiten. Dies wird häufig in Form von organigrammen dargestellt.
Mit der Ablauforganisation werden Abläufe bzw. Prozesse beschrieben. Für eine erfolgreiche prozessorientierte Organisationsgestaltung müssen zuerst die Abläufe definiert werden. Erst danach die Aufbauorganisation.

[[Image:Organisationswürfel.jpg|Organisationswürfel]]

=== 2.2 Elemente der Organisation ===

'''Aufgaben'''

Aufgaben sind die zentralen organisatorischen Elemente. Sie werden im Rahmen der Aufbauorganisation verteilt. Die Prrozesse der Aufgabenerfüllung werden im Rahmen der Ablauforganisation geregelt.

Aufgaben lassen sich von Aufträgen wie folgt unterscheiden:
*Aufgaben sind dauerhaft wirksame Aufforderungen, Verrichtungen an Objekten zur Erreichung von Zielen durchzuführen.
*Aufträge sind einmalige Aufforderungen, Verrichtungen an Objekten zur Erreichung von Zielen durchzuführen.

'''Aufgabenträger'''

..sind immer Menschen. Werden durch verschiedene Faktoren bestimmt: Motivation, Denkweise, Erfahrung, Rollen, unterschiedliche Leistungsbereitschaft.

'''Sachmittel'''

..sind Instrumente die zur Erfüllung der Aufgabe eingesetzt werden. Sie entlasten den Aufgabenträger und verbessern dessen Leistung.

'''Informationen'''

..werden benötigt um den Aufgabenträger bei der '''Aufgabenerfüllung''' zu unterstützen. Bei der Erfüllung von Aufgaben entstehen neue Informationen welche von anderen Aufgabenträgern benötigt werden.
Die '''Informationsstruktur''' stellt die Gesamtheit aller Informationen innehrlab des Unternehmens dar.

Informationssysteme bilden das Beziehungsgefüge zwischen Informationen, Informationsprozessen, Aufgabenträgern und Aufgaben. Sie diesen weiter zur Steuerung betrieblicher Prozesse.

=== 2.3 Dimension der Organisation ===

Eigenschaften der Elemente: Zeit, Raum, Menge, Art, Qualität

'''Menge'''

...wird in einer Zahl ausgedrückt und muss sich immer auf etwas beziehen (Anzahl teile pro Tag, Anzahl Aufgaben)

'''Zeit'''

definiert Zeitpunkt, Zeitdauer oder Zeitraum

*Start- Endzeit
*Eingang von Inputs oder Outputs
*Termine
*Durchlaufzeit
*Bearbeitungszeit
*Transportzeit
*Leigezeit
*Rüstzeit
*etc.

'''Raum'''

*Raumbedarf messen
*Standorte von Sachmitteln, Arbeitsplätzen, Organisationseinheiten bestimmen.

=== 2.4 Beziehungen der Organisation ===

[[Image:MerkmaleAufgaben.PNG]]

Raum, Zeit und Menge = Ablauforganisation, Rest = Aufbauorganisation

=== 2.5 Organisation gestalten ===

Im Rahmen der Aufbauorganisation werden Stellen gebildet indem Aufgaben so zusammengefasst werden, dass das Volumen von einem Aufgabenträger bewältigt werden kann. Anschliessend werden geeignete Aufgabenträger, Sachmittel und die notwendigen Informationen zugeordnet. In einem weiteren schritt werden statische Beziehungen zwischen den Stellen hergestellt.

Die Gestaltung der Ablauforganisation richtet sich unter anderem nach folgenden Zielen:

*Minimierung der Durchlaufzeit
*Maximierung der Kapazitätsauslastung
*Minimierung der Wegzeiten
*Standardisierung der Verrichtungsfolgen
*Minimierung der Ressourcennutzung

== 3 Grundlagen der Prozessorganisation ==

Das "neue" '''Denken in Prozessen''' und die '''Ausrichtung der Prozesse auf den Kunden''' ist für das Überleben entscheidend.

[[Image:ProzessorientiertOrganisieren.jpg]]

=== 3.1 Geschäftsprozess-Management ===

Das Geschäftsprozess-Management ist ein ganzheitliches Managementkonzept das eine zielgerichtete Steuerung und Optimierung der Geschäftsprozesse ermöglicht und zu einer nachhaltigen Verbesserung der Wettbewerbsposition führt.

Im Rahmen der '''Prozessentwicklung''' werden bestehen Abläufe erhoben und analysiert. Auf Basis dieser Ergebnisse werden die Prozesse neu gestaltet und textlich bzw. grafisch dargestellt.

Die '''Prozessmodellierung''' ist Teil der Prozessentwicklung welche folgende Ergebnisse liefern sollte:

*Grafische Darstellung der Prozesse
*Ergänzende und vertiefende textliche Prozessdokumentationen
*Definierte Prozesskennzahlen
*Definierte Prozessrollen und Prozessbeteiligte

Das Geschäftsprozess-Management lässt sich anhand folgender Begriffe charakterisieren:

*Kundenorientierung
*Wertschöpfungsorientierung
*Strategieorientierung
*Prozessführung
*Leistungsorientierung
*Prozessverantwortung
*Mitarbeiterorientierung
*Kompetenzorientierung

=== 3.2 Zum Begriff "Prozess" ===

Es gibt verschiedenen Definitionen welche alle mehr oder weniger das selbe bedeuten. Im Hinblick auf den Geschäftsprozess lassen sich folgende Aussagen machen:

*Eine Menge von Aufgaben die einen festgelegten Anfang und ein festgelegtes Ende haben. Sie werden ausserdem in einer festgelegten Folge ausgeführt.
*Ein Geschäftsprozess beeinflusst die Wettbewerbsposition nachhaltig.
*Die Wertschöpfung eines Geschäftsprozess besteht darin, Input mittels Arbeitsleistung zu Outputs mit höherem Wert umzuformen und an Prozesskunden auszuliefern
*An einem Geschäftsprozess können mehrere OE beteiligt sein.

=== 3.3 Wichtige Begriffe um den Geschäftsprozess ===

[[Image:WichtigeBegriffeGeschäftsprozess.jpg]]

== 3.4 Funktions vs. prozessorientierte Organisation ==

'''Funktionsorientierte Organisation'''
*Bis vor kurzem aktuell
*Merkmale der Organisationsstruktur: Funktion, Produkt, Region
*Spezialisierung und effiziente Nutzung der Ressourcen
*funktional orientierte und hierarchische Organisation
*Bei kleinen Unternehmen kein Problem (weil überschaubar und alle kennen sich)
*nimmt wenige Rücksicht auf Kundenbedürfnisse
*Gesamtzusammenhang der betrieblichen Funktion tritt in den Hintergrund
*Hohe Kosten für die Koordination zwischen den Bereichen

'''Prozessorientierte Organisation'''
*Im Mittelpunkt steht die Ablauforganisation
*Die Ablauforganisation befasst sich mit der Aufgabendurchführung sowie der zeitlichen und räumlichen Aspekte der Aufgabendurchführung (Wer mach wa, wann, wo und womit?)
*Elementare Teile der Aufgabe sind Aktivitäten (Grundstein Arbeitsprozess)
*Eine Geschäftsprozess ist die zeitliche und logische Folge von Aktivitäten.
*Die Prozessziele lassen sich besser mit den Kundenzielen in Übereinstimmung bringen
*Marktorientierung
*Ergebnisorientierung
*Geschäftszielorientierung

== Ansätze einer prozessorientierten Reorganisation ==

*Sollen bestehen Abläufe erhoben, analysiert oder dokumentiert werden?
*Sollen bestehende Prozesse optimiert werden?
*Oder sollen die Prozesse völlig neu gestaltet werden?

Es gibt zwei grundsätzlich verschiedene prozessorientierte Reorganisationen:

*Geschäftsprozess-Optimierung
*Business Process Reengineering

'''Geschäftsprozess-Optimierung (GPO)'''

*Evolutionäre, schrittweise Verbesserung von Prozessen
*Bestehende Abläufe sind Ausgangspunkt
*Bestehende Abläufe werden auf Schwachstellen untersucht und schrittweise optimiert
*Bestehende Stärken werden ausgebaut
*Der Fokus liegt auf den einzelnen Prozessen
*Aufbau auf bestehende Organisationsstruktur
*Voraussetzung: Bestehende Prozesse
*geringes Risiko
*kann bei der Einführung einer BWL Standardsoftware durchgeführt werden.

'''Business Process Reengineering (BPR)'''

*Unternehmen wird neu entworfen
*Auf der grünen Wiese anfangen
*Alle Prozesse und Organisationsstrukturen werden neu definiert
*Ausgangspunkt ist die Unternehmensstrategie (Geschäftsziele, Geschäftsfelder, Erfolgsfaktoren, Kernkompetenzen)
*Ziel: Wünsche der internen und externen Kunden effektiver und effizienter zu befriedigen
*"Structure follows process follows strategy" Die Strategie bestimmt die Prozesse und die Prozesse bestimmen die Organisationsstruktur
*Unternehmen wird neu erfunden
*weitere Ziele: stärkere Kundenorientierung, höhere Flexibilität, kürzere Lieferzeiten, mehr Kosteneffizienz, bessere Qualität, höhere Mitarbeiterzufriedenheit
*Oberstes Management muss sich beteiligen
*Top-down-Ansatz
*Gefahr, dass Betroffenen ungenügend beteiligt werden -> Hauptgrund für Scheitern des BPR
*Hoher Umsetzungsaufwand
*Hohes Risiko
*Grosses Konfliktpotenzial

== 3.6 Ziele der Prozessorganisation ==

'''Kundenorientierung'''

*Ein Prozess wird durch eine Kundenanforderung ausgelöst und das Ergebnis geht zurück an den Kunden.
*Die grundlegende Kenngrösse für die Steuerung eines Prozesses ist die Kundenzufriedenheit
*Die aus dem Prozess resultierende Leistung muss für den Kunden einen Wert darstellen.

'''Konzentration auf die Wertschöpfung'''
*jede Aktivität welche für den Kunden einen Wert darstellt dient zur Wertschöpfung (herstellen eines Teils, aber nicht Lagern eines Teils)
*Geschäftsprozesse die eine Wertschöpfung für den Kunden darstellen werden als '''primäre Prozesse''' bezeichnet.
*geschäftsprozesse die für das Unternehmen zwar notwendig sind, aber keinen Beitrag zur Wertschöpfung leisten, werden als '''sekundäre Prozesse''' bezeichnet.

'''Orientierung auf interne und externe Kunden'''

*jeder Prozess ist Kunde des vorhergehenden und zugleich Lieferant des nachfolgenden Prozess
*jeder Prozess benötigt Input einer definierten Qualität um selber eine gute Leistung erbringen zu können.

'''Effektivität und Effizienz'''

Ein Zeil der Prozessorganisation ist die Steigerung von Effektivität und Effizienz.

*Definition Effektivität: Das gewünschte Ergebnis bzw. die gewünschte Wirkung wird erreicht. Effektivität bedeutet das richtige zu tun. Steht für die Aussensicht der Prozesse: Entsprechen die Leistungen den Erwartungen des Kunden.
*Definition Effizienz: Das gewünschte Ergebnis wird wirtschaftlich erreicht (minimaler Ressourceneinsatz). Effizienz bedeutet etwas richtig zu tun. Steht für die Innensicht des Prozesse: Werden die Prozesse mit dem kleinstmöglichen Ressourceneinsatz durchgeführt?

'''Prozesseffizienz'''

*Traditionell wird die Effizienz durch '''Kostensenkungsmassnahmen''' gesteigert.
*Im Rahmen des Geschäftsprozess-Managements werden zusätzlich die Kriterien '''Zeit''' und '''Qualität''' in Betracht gezogen.

'''Prozesseffizienz''': Produkte sollen in möglichst kurzer Zeit mit möglichst niedrigen Kosten in möglichst hoher Qualität hergestellt werden.

=== 3.7 Schnittstellenmanagement ===

Schnittstelle =
*Verantwortung geht von einer Person zu einer anderen..
*..oder von einer OU auf eine andere

'''typische Schnittellenprobleme'''
*Verlängerung Durchlaufzeiten wegen gestörten Material- oder Informationsflüssen
*Reibungsverluste aufgrund verschiedenen Zielen
*Kommunikationsprobleme
*Mangelnde Abstimmung
*Abweichende Kulturen
*Konflikte
*Unterschiedliche Art der Informatikunterstützung (Medienbrüche)

Ein wesentliches Ziel der prozessorientierten Organisation ist es, durchgängige Prozesse mit möglichst wenig Schnittstellen zu gestalten. Bei einem Übergang von der funktionsorientierten zur prozessorientierten Organisation ist eine zentrale Forderung die Reduktion bzw. Harmonisierung der Schnittstellen.

Verbleibenden Schnittstellen müssen optimiert werden. (Schnittstellenmanagement)

'''Darstellungstechniker für Schnittstellen'''

*Schnittstellenmatrix wird verwendet
*Beim Prozessmanagement kann die '''Prozesslandkarte''' herangezogen werden.

Inhalt Prozesslandkarte:
*komplettes Netzwerk der internen und externen Prozessen.
*Verfeinerung der Darstellung im Kontextdiagramm
Detaillierte Beschreibung der Schnittstellen (Leistungsbeschreibung, technische Schnittstellenbeschreibung, Leistunsgvereinbarung (z.B. SLA)

=== 3.8 Strukturierungsgrad von Prozessen ===

'''Wohlstrukturierte Prozesse'''

*vollkommen planbar
*evtl. programmierbar
*hohe Wiederholungsrate
*bekannter Ablauf
*lassen sich durch Wokrflow-Managementsysteme (FWMS) unterstützen und eigenen sich zur Automatisierung.

'''Teilstrukturierte Prozesse'''

*sind bis zu einem bestimmten Grad planbar
*je nach Geschäftsfall kommen bestimmte Ablauffolgen zum Tragen
*es gibt aber Ausnahmen
*können durch Groupware-Systeme gut unterstützt werden.

'''Unstrukturierte Prozesse'''

*komplexe Problemstellung
*unbestimmter Informationsgehalt
*im Ablauf nicht vorhersehbar
*nicht planbar
*zur Unterstürzung kommen am ehesten Systeme zur Entscheidungsunterstützung (t.B. Date-Warehouse) in Frage.

== 4 Unternehmensmodellierung ==

'''Grundsatz''': Von der Strategie zu den Prozessen zu den Informationssystemen

=== 4.1 Von der Strategie zu den Prozessen ===

*Unternehmensziel muss klar sein
*Strategie definieren!
*Die Strategie ist die Grundlage der Organisation des Unternehmen
*Auf Grund der Strategie werden die Prozesse gestaltet.

*Wertsteigernde Aktivitäten werdenals '''Wertschöpfungskette''' dargestellt.
*Diese Aktivitäten müssen billiger und besser als von der Konkurrenz erledigt werden (Wettbewerbsvorteil)

*Die '''primären Aktivitäten''' der Wertschöpfungskette befassen sich mit dem Erstellen, dem verkauf und der Güter sowie dem Kundenservice.
*Die '''unterstützenden Aktivitäten''' beeinflussen den Wert nur indirekt. Sie liefern Input an die primären Aktivitäten.

'''Prozesstypen'''

In Anlehnung an die Wertschöpfungskette werden folgenden '''Prozesstypen''' unterschieden:

*'''Wertschöpfungsprozesse''' (auch Kernprozess, Leistungsprozesse, primäre Prozessen). Das Ergebnis dieses Prozess stellt für den Kunden einen Wert dar für welchen der Kunde bereit ist etwas zu bezahlen. Wertschöpfungsprozesse entsprechen den Kernkompetenzen eines Unternehmens.
*'''Unterstützungsprozesse''' (auch Supportprozesse, sekundäre Prozesse). Sind für für die Wertschöpfungsprozesse notwendig. (Beispiel: Inkasso, Personalwesen, Informatik)
*'''Führungsprozesse''' (auch Managementprozesse, sekundäre Prozesse). Dienen der Staregieentwicklung. Planen, koordinieren.

=== 4.2 Prozesse modellieren ===

Ein '''Modell''' ist vereinfachtes Abbild eines System. Anhand eines Modells können die wichtigsten '''Elemente''' des Originals sowie deren '''Eigenschaften''' und '''Beziehungen''' zueinander analysiert und verstanden werden.

bei der Unternehmensmodellierung kommen verschiedenen Betrachtungsweisen zum Tragen. Wenn Sie z.B, ein ein neues SOfwtaresystem modellieren müssen verschieden Betrachtungsweisen und deren Zusammenhänge beschrieben werden. Z.B.

*Prozessschicht. (Wertschöpfungskettendiagramm, Prozesshirarchiediagramm, Ereignisgesteuerte Prozesskette (ARIS), Aktivitätendiagramm (UML)
*Organisationsschicht (Organigramm)
*Datensicht(Entity-Relationship-Diagramm, Klassendiagramm (UML), Zustandsdiagramm (UML))
*Funktionssicht (Funktionsbaum)

'''Prozesshierarchie'''

*Üblicherweise werden nicht nur die einzelnen Detailprozesse modelliert, sondern es wird eine Prozesshierarchie aufgebaut.
*Die oberste Ebene der Hierarchie ist das Unternehmen.

*Auf der obersten Ebene liegt die Prozesslandkarte
*Auf der untersten die Elementarprozesse. dieser werden meist in Form von Abläufen dargestellt.
*Dazwischen gibt es verschiedene Modelle die eine Prozesszerlegung ermöglichen.

=== 4.3 Von den Prozessen zum Informationssystem ===

*Das Informationssystem soll die Geschäftsprozesse unterstützen
*Die Gestaltung der Geschäftsprozesse und die Gestaltung der Informationssystem lassen sich nicht mehr voneinander trennen.
*Zuerst die Prozesse, dann das Informationssystem

# Strategie überprüfen, falls nötig ergänzen, dann daraus Prozesse ableiten
# Prozesse unter Berücksichtigung der Informatik gestalten
# Anforderungen an die Anwendungssystem aus den Prozessen ableiten
# Anwendungssystem modellieren und entwickeln oder solche kaufen welche die Prozesse unterstützen.

== 5 Ist-Modellierung ==

*Ist es sinnvoll die Ist-Prozesse zu modellieren?
*Wenn ja, wie detailliert?

=== 5.1 Einflussfaktoren ===

'''Zielsetzungen für eine Ist-Modellierung'''

*Aufzeigen welche Prozesse bereits vorhanden sind.
*Arbeitsabläufe dokumentieren
*Segeln, Vorschriften, Fähigkeiten identifizieren
*Schwachstellen finden

'''Argumente für eine Ist-Modellierung'''

*Um eine Verbesserung zu erwirken muss man die Ist-Situation kennen.
*Ist gut für die Einarbeiter der Mitarbeiter in die Methoden und die Tools
*Ist-Modelle können evtl. bei der Soll-Modellierung weiter benutzt werden.
*Vergleich von Ist und Soll wird möglich
*Bei der GPO (Geschäftsprozessoptimierung) ist die Ist-Modellierung notwendig, da vom bestehenden ausgegangen wird.

'''Argumente gegen eine Ist-Modellierung'''

*Hemmt die Kreativität
*Es besteht die Gefahr, dass alte Strukturen übernommen werden.
*Das Erstellen eines Ist-Modell kann mit hohem Aufwand verbunden sein.

=== 5.2 Vorgehensweise ===

Phasen und Tätigkeiten bei der Ist-Modellierung

'''Vorbereitung''':
*Verantwortlichkeiten definieren
*Geeignete Fachexperten als Interviewpartner auswählen
*Informationsquellen identifizieren
*Inhalt und Form der Prozessdokumentation festlegen
*Beschreibungssichten wählen (z.B. Organisation, Prozess, Funktionen)
*Rahmenmodell (Prozesslandkarte) erstellen
*Prozesshierarchie festlegen (Anzahl Ebenen, Modelltyp pro Ebenen)
*Detaillierungsgrad bestimmen
*Modellierungskonventionen erarbeiten
*Mitarbeiter einladen und planen
*Weitere Aktivitäten planen

'''Untersuchungsbereiche definieren:'''
*Untersuchungsbereiche abgrenzen und zerlegen
*zusammengehörende Prozesse in Gruppen zusammenfassen (Beispiel: Frontoffice, Backoffice) (Modellierungskopmplexe bilden)
*Schnittstellen zwischen den oben definierten Gruppen (Modellierungskopmplexe)identifizieren
*Zusammenhänge zwischen den Prozessen grob erfassen
*Prioritäten der zu modellierenden Prozesse festlegen

'''Ist-Modell erheben:'''
*Workshopfs für die Erhebung planen und durchführen
*Ist-Modell grafisch erfassen
*Schnittstellen zwischen den prozessen identifizieren
*Inhaltlicher Review der Ist-Modelle mit den Fachexperten
*Formaler Review der Ist-Modelle mit Methodenexperten

'''Konsolidierung:'''
*Modell auf Konsistenz prüfen
*auf Vollständigkeit prüfen
*Ist-Modell konsolidieren
*Ist-Modelle zu einem Gesamtmodell zusammenführen (Verknüpfungen definieren)

'''Ist-Modell analysieren:'''
*Analysekriterien definieren
*Checklisten erstellen
*Schwachstellen und Verbesserungspotenziale identifizieren und dokumentieren
*Schnittstellen identifizieren
*Sofortmassnahmen zur Beseitigung der dringendsten Schwachstellen festlegen und realisieren

=== 5.3 Ergebnisse analysieren ===

Befundformular für gefundene Schwachstellen erstellen:

Inhalt z.B.: Bezeichnung, Ursachen, Verbesserungspotenzial, Liste der OU, Dringlichkeit, Lösungsmöglichkeiten, geschätzter Aufwand.

Checkliste mit den üblichsten Schachstellen erstellen. Problembereiche: Informatik, Ablauforganisation, Aufbauorganisation, Schnittstellen.

== 6 Informationen sammeln ==

Informationssammlung muss im Allgemeinen im Zusammenhang mit einer '''Problemlösung''' gesehen werden.

Vorgehensweise:
#Informationen sammeln
#Erhobene Infos aufbereiten und analysieren
#Ziele festlegen
#Eine oder mehrere Lösungen entwerfen
#Lösungsvarianten analysieren
#Lösungsvarianten anhand der Ziele vergleichen
#Favorisierte Lösungsvariante auswählen

'''Zweck der Informationserhebung'''

Beispiele:
*Organisation neu gestalten
*Prozesse optimieren
*Entscheide vorbereiten
*Applikationen entwickeln

Bei der Informationserhebung empfiehlt es sich, vorgängig einen Raster aufzustellen welcher als Ideengeben oder Checkliste verwendet werden kann. (Was ist zu tun, Wie ist es zu tun, wie lange, wer, was wird benötigt, Qualifikationen, etc.)

Die Ergebnisse können in Text-, Tabellen- oder Grafikform dargestellt werden.

=== 6.2 Erhebungstechniken ===

'''Dokumentstudium:'''
*Vom Schreibtisch aus
*Betroffene werden oft nicht einbezogen
*Steht oft am Anfang um sich in die Materie einzuarbeiten (Grundlagenforschung)

Es wird zwischen '''planmässig''' und '''ad hoc''' erstellen Dokumenten unterschieden

Beispiel "Planmässig":
*Stellenbeschreibung
*Arbeitsanweisung
*Durchführungsverordnung
*Ablaufbeschreibung

Beispiel "ad hoc":
*Sitzunsgberichte
*Protokolle
*Prüfungsberichte
*Aktennotizen

Probleme des Dokumentenstudium:
*oft nicht aktuelle
*evtl. lückenhaft
*wichtige Dokumente fehlen

Vorteile des Dokumentenstudium:
*breite Informationsbasis
*keine Störung des Betrieben
*gute Basis

'''Interview:'''
*gut geeignet für das Erhebung qualitativer Merkmale und das Aufdecken von Problemen
*ist aufwändig
*Ziel und Fragenkatalog müssen zu Beginn festgelegt werden.

'''Fragebogentechnik:'''
*leistungsfähig wenn es um quantitative Sachverhalte handelt und es eine grössere Anzahl Personen betrifft.
*1.homogener Personenkreis festlegen
*2.Fragebogen entwerfen (Eindeutige Fragen, evtl. standardisierte Antwortmöglichkeiten)
*Fragebeogen testen
*Rücklauf prüfen und auswerten

'''Multimomentstudie'''
*Ziel: Von einer begrenzen Anzahl beobachteter Fälle auf die gesamtheit alelr Fälle schliessen.
*Zu diesem Zweck wird ein bestimmter Sachverhalt mehrfach beobachtet und notiert.

Es gibt "Multimoment-Zählverfahren" und "Multimoment-Zeitmessverfahren"

'''Selbstaufschreibung'''
*der Aufgabenträger führt selber Beobachtungen durch und notiert diese.
*Wird angewendet um Aufgaben unter Angabe von zeit und Menge zu erheben.
*Es werden leicht verständliche Formulare verwendet

'''Laufzettelverfahren'''
*Es wird ein Laufzettel(Beleg, Akte) wie ein Begleitpapier einem Auftrag angehängt.
*Dieser durchläuft den ganzen Prozess und wird überall ausgefüllt

Ergebnis:
*Wer ist beteiligt?
*Welche Verzweigungen gibt es?
*Wie häufig wird verzweigt?
*Durchlaufzeiten, Bearbeitungszeiten, Liegezeiten, Transportzeiten
*Wieviel Rückläufe

== 7 Soll-Modellierung ==

*Ziel: Prozesse so gestalten wie sie später umgesetzt werden sollen.
*Vorgabe für Rollout der Prozesse

=== 7.1 Einflussfaktoren ===

*Wichtig: Zielsetzung der Soll-Modellierung festlegen
*Ziele dienen später zur Beurteilung der Modelle.

Beispiele für interne Ziele:
*Effizienzsteigerung (Kostenreduktion, Straffung von Abläufen)
*Reduktion von Planung und Bearbeitungszeiten
*aktueller Infos
*bessere Kommunikation
*Minimierung von Schnittellen

Beispiele für externe Ziele:
*Effektivitätssteigerung
*grössere Kundenbindung
*beschleunigte Kommunikation mit Kunden
*erhöhte Flexibilität bei Marktentwicklungen

=== 7.2 Vorgehensweise ===

Phasen und Tätigkeiten der Soll-Modellierung

*Vorbereitung: Interviewpartner auswählen, Verantwortlichkeiten definieren, Beschreibungssichten währen (z.B. Organisation, Prozesse, Funktion), Rahmenmodell (Prozesslandkarte) entwerfen, Prozesshierarchie festlegen, Mitarbeiter einarbeiten, prüfen ob Referenzmodelle verfügbar sind, weitere Aktivitäten planen
*Grobentwurf: Wertschöpfungsprozesse aus der Unternehmensstrategie ableiten, notwendige Supportprozesse und Managementprozesse definieren, Prozessstrukturen der ersten Ebene erstellen.
*Soll-Modelle erheben: Soll-Aufnahme-Workshops durchführen, Soll-Modelle grafisch erfassen, Inhaltlicher und formaler Review, Prozess-Varianten bilden, Soll-Modelle dokumentieren.
*Konsolidierung: Modelle auf Konsistenz und Vollständigkeit prüfen, Modelle zu einem Gesamtmodell zusammenführen
*Aufbauorganisation definieren: Stellen und Rollen aufgrund des auszuführenden Funktionen bilden, Stellen den OE zuordnen, Organigramm aufbauen.
*Aufbereitung und Veröffentlichung: betriebliche Dokumentation erstellen, Prozesse-Modelle im Intranet veröffentlichen, Modelle durch geeignete Dokumente ergänzen, Präsentationen und Schulungsunterlagen erstellen.

=== 7.3 Prozessdokumentation ===

mögliche Zielsetzungen für eine Prozessdokumentation:
*gemeinsame Kommunikationsbasis bilden
*bestehende Abkläufe dokumentieren
*Qualität sichern (z.B. ISO 9000:2000)
*Schwachstellen erkennen
*bestehende Abläufe optimieren.
*neue Abläufe entwerfen
*Bedarf an Unterstützung durch Applikationen erkennen

Eine Prozessdokumentation besteht in der Regel aus folgenden '''Elementen''':

*Geschäftsprozess-Beschreibung
*Prozessablauf
*Prozess-Organisations-Diagramm
*Leistungsvereinbarung zwischen Kunden und Lieferanten
*Beschreibung von Aufgaben, Verantwortung und Befugnissen der Prozessbeteiligten (Prozessmanager, Prozesseigner, Prozessteam)

Um einen Prozess genau zu beschreiben sind eine Reihe von Informationen notwendig. z.B.
*Start und Ende eines Prozesses
*Welche OE durchlebt er
*welche Ergebnisse werden erwartet
*wer sind die Abnehmer
*Durchlaufzeit
*Schnittstellen

=== 7.4 Gestaltungselemente ===

Bestandteile eines Prozesses:
*wird durch einen vorgelagerten Prozess angestossen. Dazu gehört eine Schnittstelle und eine Eingabe. Die Eingabe muss einer Eingabeprüfung unterzogen werden.
*Ein Prozess liefert ein Ergebnis an einen nachgelagerten Prozess. dazu muss eine Schnittstelle definiert werden. Vor der Auslieferung wird das Ergebnis geprüft.
*Damit eine Prozess durchgeführt werden kann, ist er im Allgemeinen auf die Zulieferung weiteren Leistungen angewiesen (andere Prozesse). Dazu gibt es weitere Schnittstellen und Eingabeprüfungen.
*Ein Prozess besteht aus einer Folge von Aktivitäten. Die erste Aktivität wird durch das Eintreffen der Eingabe ausgelöst, die letzte führt zur Auslieferung des Ergebnisses.
*Die Qualität wird durch Kenngrössen bestimmt. Dabei soll sich die '''Messgrösse''' der '''Zielgrösse''' annähern.
*Der Prozessverantwortliche ist zuständig für Gestaltung, Führung, Durchführung, Messung und Verbesserung des Prozesses

[[Image:Prozessbestandteile.JPG]]

Allgemeine Regeln:

*jeder Prozess beginn und endet bei einem Kunden.
*Ein Prozess beginnt und endet mit einem Ereignis
*Bei der Bezeichnung eines Prozesses wird neben dem Prozessnamen auch das Anfangs- und Endpunkt angegeben.
*Jeder Prozess wird so lange in Teilprozesse und Prozessschritte unterteilt, bis sinnvolle elementar Aktivitäten definiert sind.
*Teilprozesse und Prozessschritte ohne Wertschöpfung werden so weit als möglich eliminiert.

Kunden- und lieferantenbezogene Regeln:

*Kunden und Prozessergebnisse müssen festgelegt werden.
*Am Anfang jedes Geschäftsprozesses steht eine Leistungserwartung des Kunden und er endet mit der Übergabe der Leistung an den Kunden.
*Jeder Geschäftsprozess benötigt Inputs um Leistung erstellen zu können.
*Inputs werden von Zuliefern zur vErfügung gestellt (also von anderen prozessen)
*Um die Inputs von internen und externen Zulieferern zu garantieren ist es notwendig mit diesen vereinbarungen über die Bereitstellung der Inputs zu treffen.
*Zulieferer sind andere interne Geschäftsprozesse oder externe Lieferanten, aufgefasst als externe Prozesse

'''Ablauforganisatorische Gestaltungsmassnahmen''':

[[Image:GestaltungProzessablauf.JPG]]
[[Image:GestaltungProzessablauf2.JPG]]

'''Aufbauorganisatorische Gestaltungsmassnahmen''':

*Für jeden Geschäftsprozess wird ein ein Prozessverantwortlicher (Owner) definiert.
*Dem Verantwortlichen wird ein Prozessteam zugewiesen
*Die personifizierte Prozessverantwortung ist ein wichtiger Erfolgsfaktor.
*Der Prozessverantwortliche ist zuständig für Gestaltung, Führung, Durchführung, Messung und Verbesserung des Prozesses

'''Betriebswirtschaftliche Gestaltungsmassnahmen''':

*Ein Prozess besteht aus vielen Tätigkeiten welche gemeinsam zum Produkt führen. Aus Sicht des Unternehmens erhöht jeder Schritt den Wert des Prozessergebnisses - aus Sicht der Kunden aber nicht unbedingt.

=== 7.5 Grundsätzliche Darstellungsformen ===

Um Prozesse zu beschreiben kommen verschiedenen Darstellungsformen zum Einsatz

*Textform: Meist Vorgabe bzw. Vorlage für die grafische Umsetzung.
*Tabellenform: Vorteile = gut strukturiert, übersichtlich, Prozessschritte können mit Detailinfos kombiniert werden. Nachteil = Nicht anschaulich, logisch Verzweigungen können nur umständlich beschrieben werden.
*Grafische Darstellung: Dafür gibt es viele Darstellungsformen. In der Praxis wird meist eine Variante des Prozessablaufplanes (auch: Flussdiagramm) verwendet. Vorteile = Übersichtlich, Anschaulich. Nachteile: Durch zu viele Detailinfos kann die grafische Übersicht an Übersichtlichkeit verlieren.

'''Auswahlkriterien für Darstellungsform'''

*Wichtig für Akzeptanz durch die Zielgruppe
*muss geeignet sein
*logisch everbindungen müssen aufgezeigt werden

=== 7.6 Referenzmodelle ===

*ist formale oder halbformale Beschreibung von Tatbeständen, die auf Best-Practice-Wissen beruht und einen bestimmten Grad und Allgemeingültigkeit und Übertragbarkeit besitzt.
*Referenzmodell sind zum teil in Büchern oder in elektronischer Form verfügbar (oder in Modellierungstools)
*erleichtern den Einstieg in die Soll-Modellierung
*Ideensammlung
*bieten eine gute Diskussionsbasis
*muss am Schluss individualisiert werden.

== 8 Grafische Darstellung ==

Es steheneine Vielzahl von Techniken zur Verfügung

=== 8.1 Prozesslandkarten ===

*Ziel Prozesslandkarte (PLK)= Überblick/Abgrenzung über Untersuchungsbereich. Schnittstellen zum Umfeld aufzeigen
*wird manchmal auch Prozessarchitektur genannt

Ein Prozess wird meist durch ein Rechteck dargestellt. Leistungen werden als Pfeile dargestellt.

[[Image:PLK.JPG]]

Eine andere Darstellungsform ist das Wertschöpfungskettendiagramm (üblich bei der ARIS Methode)

[[Image:Wertschöpfungskettendiagramm.JPG]]

Es gibt auch die Variante bei welcher bei der Prozesslandkarte zwischen primären und sekundären Prozessen unterschieden wird:

[[Image:PLK mit Prozessbereichen.JPG]]

=== 8.2 Prozessumgebung ===

Das Kontextdiagramm zeigt einen Hauptprozess und dessen Umgebung. Es ist wie eine prozesslandkarte, allerdinsg wird nur ein einzelner Prozess (und seine Umgebung) dargestellt.

[[Image:Kontextdiagramm.JPG]]

=== 8.3 Prozesshierarchie ===

Eine Prozesshierarchie entsteht wenn Prozesse stufenweise in Teilprozesse gegliedert werden. Auf der obersten Abstraktionsstufe liegt der Hauptprozess der in der Prozesslandkarte zu sehen ist.

*Prozessgliederung entspricht dem Vorgehen der Aufgabenanalyse
*Aufgaben werden so lange in Teilaufgaben zergliedert,als sinnvolle Teilaufgaben identifiert werden können.

Die Benennung der Hirarchiestufen hängt von der Methode ab. Bei der Promet-Methode spricht man z.B. von Makro-Prozessen die in Mikro-Prozesse aufgegliedert werden.

[[Image:Prozessstufen.JPG]]

Beispiel Prozesshierarchie

[[Image:Prozesshirarchiediagramm.JPG]]

=== 8.3 Prozessabläufe ===

*Es gibt verschiedene Techniken der Modellierung und es ist kein Standard in Sicht

'''Flussdiagramm'''

*wurden vor allem in den 60'er und 70'er Jahren eingesetzt
*wurde durch DIN-Norm 66001 vereinheitlicht.
*einfach lesbar
*entspricht der Notation des Datenflussplan, wird aber in der Praxis mit anderen Symbolen angereichert

Zwei spezielle Ausprägungen stellen in der Informatik der Datenflussplan und der Ablaufplan dar

[[Image:Flussdiagramm.JPG]]

'''Datenflussplan'''
*Symbole nach DIN 66001 genormt
*stellt den Fluss der Daten durch ein Informationssystem dar.

Symbole für Datenflusspläne

[[Image:SymboleDatenflussplan.JPG]]

Schablone für DIN 66001

[[Image:SchabloneDIN66001.JPG]]

Im Rahmen der ISO 9000 Zertifizierung ist es üblich debn Datenflussplan mit zusätzlichen Informationen anzureichern. z.B
*Zuordnen der verantwortlichen Stelle
Besschreibung von Input und Output

Wird auch "stellenorientierter Ablaufplan" genannt.

[[Image:Stellenorientierter Ablaufplan.JPG]]

'''Ereignisgesteuerte Prozesskette (EPK)'''

*ist Bestandteil von ARIS
*beschreiben den Ablauf indem sie den auslösenden Prozess und die erzeugten Ereignisse darstellen
*in der erweiterten ereignisgesteuerte Prozesskette (eEPK) werden noch zusätzliche Objekte abgebildet (z.B. Input, Output, OE, Leistungen, etc.)
*Die einfachste Form enthält nur Ereignisse, Funktionen und logische Verzweigungen

[[Image:EPK.JPG]]

EPK mit Spalten

[[Image:EPK Spalten.JPG]]

'''Aktivitätendiagramm'''

*für die objektorientierte Modellierung wird UML als Standard betrachtet.
*UML ist gut für Darstellung von Prozessabläufen geeignet
*Aktivitätendiagramm besteht aus Folgen von Aktivitäten und Zustandsübergängen.
*vergleichbar mit Flussdiagramm bzw. Programmablaufplan
*kann zur Beschreibung prozeduralen Abläufen, Geschäftsprozessen, Anwendungsfällen oder Operationen verwendet werden.
*ermöglicht die Darstellung paralleler Prozesse mit Hilfe von Synchronisationsbalken

Symbole

*Aktiviät = abgerundetes Rechteck
*Pfeile = Übergänge (Abschluss einer Aktivität und Übergang zur nächsten)
*Rauten = logische Verzweigungen
*Eine Synchronisation führt mehrere parallele Zweige zusammen.
*ein Splitting teiln in mehrere parallele Zweige

[[Image:Aktivitätendiagramm.JPG]]

Aufgabenkettendiagramm

*gehört zur Promet-Methode
*dokumentiert den Ablauf eines Makro- bzw. eines Mikorprozess

[[Image:Aufgabenkettendiagramm.JPG]]

== 9 Kennzahlen als Grundlage der Prozessführung ==

*kritische Erfolgsfaktoren (KEF) müssen identifiziert, steuerbar und kontrollierbar sein.
*dazu müssen die Führungskräfte jederzeit aktuelle Infos haben welche als Grundlager für Entscheidungen dienen

'''Führungsinformationssysteme (FIS)'''
*versorgt das Management umfassend mit Informationen
*ermöglicht Entscheidungen durch das Management

'''Kennzahlen'''
*Informationen über betriebswirtschaftliche Tatbestände
*verdichten Informationen in einer Zahl
*erlauben Analyse des Geschehens
*sind Instrument zur Unternehmensführung

=== 9.1 Kritische Erfolgsfaktoren ===

*Faktoren welche über den Erfolg oder Misserfolg der strategischen Unternehmensziele entscheiden sind KEF.
*Bei der KEF-Analyse werden in einem Tow-down-Ansatz ausgehend von den Unternehmenszielen die KEFs ermittelt.
*für diese werden Messgrössen und Messverfahren definiert.

=== 9.2 Kenngrössen ===

*geben Auskunft über den Leistungsstand und Entwicklung eines Geschäftsprozesses
*von der richtigen Auswahl hängt der Erfolg der Prozesssteuerung ab. (und damit die Wirkung des Geschäftsprozess-Managements)
*mit der Zielgrösse wird ein Sollwert angegeben den die Messgrösse erreichen soll.
*Das Messverfahren beschreibt das Vorgehen wie die Messgrösse ermittelt wird.

=== 9.3 Kenngrössen ableiten ===

*werden aus strategischen Vorgaben abgeleitet
*konkreter Ansatz = Ableitung von Kenngrössen aus KEFs

Ablauf:
#Hauptprozesse bestimmen
#KEFs daraus identifizieren
#Kenngrössen aus den KEFs ableiten
#Kenngrössen mit Messgrössen operationalisieren
#Zielgrössen festlegen

=== 9.4 Prozesskenngrössen verwenden ===

*werden für verschieden vergleiche verwendet (Innerbetrieblich, Zwischenbetrieblich, Zeitvergleiche, Soll-Ist)

Folgenden Anforderungen müssen dazu erfüllt sein:

*'''Steuerungsrelevanz''': Eignen sich für Steuerung der Prozesse. Machen Handlungsbedarf sichtbar.
*'''Objektivität''': beziehen sich auf messbare Sachverhalte
*'''Akzeptanz''': sind leicht verständlich und realitätsnah. Unterstützen die Selbstkontrolle.
*'''Wirtschaftlichkeit''': Messaufwand gering, möglichst automatisch.

'''Hauptziele des Prozessmanagements'''

*Effektivität und Effizienz steigern
*KUZU sicherstellen
*Produktivität sicherstellen
*Prozesse auf Kundenbedürfnisse ausrichten
*permanente Verbesserung der Prozesse

Dazu werden Prozesskennzahlen benötigt. Deren Aufgabe sind:
*das Management mit relevanten Informationen versorgen
*Vorgaben für Informations- und Steuerungsaufgaben liefern.

Die Kennzahlen werden aus '''KEFs''' abgeleitet und durch '''Messgrössen''' und '''Messverfahren''' konkretisiert.

== 10 Allgemeine Prozesskenngrössen ==

[[Image:AllgemeineProzesskenngrössen.jpg]]

*KUZU
*Prozessqualität (Wie gut werden Kundenanforderungen erfüllt, wie fehlerhaft sind die Ergebnisse)
*Prozesszeiten (Wie schnell werden Kundenwünsche erfüllt)
*Termintreue
*Prozesskosten (Wie hoch ist der Ressourcenaufwand für die Erstellung der Leistungen)

=== 10.1 Kundenzufriedenheit ===

*zentrales Ziel des Geschäftsprozess-Management
*dazu müssen die Kundenwünsche richtig verstanden werden

'''Bedeutung der Kundenzufriedenheit'''*Basisforderung (Muss)
*Leistungsanforderung (wird vom Kunden erwartet)
*Begeisterungsanforderung (wird vom Kunden nicht erwartet)

'''Kundenzufriedenheit messen'''

*Direkte Messung (periodische Befragung beim Kunden, Befragung nach Bereitstellung von Ergebnissen)
*indirekte Messung (periodische Befragung von Mitarbeitern mit direkt Kundenkontakt, Analyse interner Messgrössen wie Kundenbeanstandungen, Beschwerden, etc.)

=== 10.2 Prozesszeiten und -termine ===

*kurze Prozesszeiten wirken sich positiv auf Effizienz und Effektivität aus.

'''Prozesszeiten messen'''

*Durchlaufzeit ist die Zeitdauer vom Anstoss bis zum bereitstellen des Ergebnisses. Sie beinhaltet neben der Bearbeitungszeit auch Transfer- und Liegezeiten. Zeiteffizienz ist dann die Bearbeitungszeit bezogen auf die Durchlaufzeit in Prozent.
*Zykluszeit ist die Duschlaufzeiten aller Zeitstrecken, auch der zeitparallelen Tätigkeiten. Lange Zykluszeiten deuten auf eine Überlastung des Prozesses hin und führen zu längeren Durchlaufzeiten.
*Termintreue ist der Anteil der ohne Terminverzug fertig gestellten Ergebnisse in Prozent

=== 10.3 Prozessqualität ===

*Prozessqualität führt zu Produktequalität und zu zufriedenen Kunden

'''messen''':
*Fehlerrate
*First Passs Yield (FPY): Anteil der ohne Nacharbeit fertig gestellten Teile
*Qualitätskosten: Vorbeugungskosten, Prüfkosten, Fehlerkosten

=== 10.4 Prozesskosten ===

*Die Prozesskostenrechnung gibt verursachergerecht Auskunft darüber welche Ressourcen von welchem Teilprozess verbraucht werden. Dies wird durch das Herstellen des Zusammenhangs zwischen Prozessleistung, Ressourcenverbrauch und wirtschaftlichem Ergebnis ermöglicht.

== 11 Kennzahlensysteme ==

*Kennzahlen (auch Indikatoren genannt) sind abhängig voneinander und müssen aufeinander abgestimmt werden.
*Sie werden deshalb zu einem Kennzahlensystem zusammengefasst

=== 11.1 Arten von Indikatoren ===

*'''Ergebniszahlen''': Messen die Auswirkung der Unternehmensaktivitäten. Sie können erst nach einer be4stimmten Zeit nach Leistungserbringung ermittelt werden. Beispiele: Rentabilität, Marktanteil, Kuzu, Kundenloyalität, Mitarbeiterqualifikation.
*'''Leistungstreiber-Kennzahlen''': zeigen auf wie die Ergebnisse zustande kommen. Können schon früh bestimmt werden und diesen deshalb als Prognosoe-Werkzeuge. Beispiele: Durchlaufzeiten, Taktzeiten, Time-to-Market.

Für ein Kennzahlensystem ist ein ausgewogener Mix aus Ergebniskennzahlen und Leistungstreibern vorteilhaft. Sonst kann man entweder nur kurzfristig planen oder man weiss nicht wie die Ergebnisse zustande kommen.

=== 11.2 Anforderungen an Indikatoren ===

*müssen ausgewogen sein und unterschiedliche Unternehmensaspekte berücksichtigen
*Das Kennzahlensystem muss Spätindikatoren und Frühindikatoren enthalten.
*Kennzahlen müssen auf den Bedürfnissen der Kunden und anderer wichtiger Interessengruppen basieren.
*Das Kennzahlensystem muss in eine Systematik der Prozessverbesserung eingebettet sein.
*Nicht die Menge der Kennzahlen ist wichtig sondern deren Qualität und Aussagekraft.
*Die Erfassung der Kennzahlen muss einfach und für die Mitarbeiter nachvollziehbar sein.

=== 11.3 Balanced Scorecard (BSC) ===

*ist ein Beispiel für ein ausgewogenes Kennzahlensystem mit allen wichtigen Betriebsdaten.
*dient zum täglichen analysieren und steuern des Unternehmensgeschehens.

Die '''BSC''' besteht aus vier Perspektiven:

*finanzielle Perspektive
*Markt- und Kundenperspektiven
*Perespektive der internen Prozesse
*lernen und Wachstum

Zu jeder dieser Perspektiven werden ein paar aussagekräftige Kennzahlen bestimmt. Diese geben Auskunft über den Zustand des Unternehmens. Ziele und Kennzahlen werden aus der Vision und Strategie abgeleitet.

== 12 Projekt "Prozessmodellierung" vorbereiten ==

Um die wichtigsten Entscheidung in der Vorbereitungsphase zu treffend müsse folgende Fragen gestellt werden:

*Welches sind die Auslöser des Projektes?
*Zielsetzungen?
*Welchen Zweck sollen die Modelle erfüllen?
*Welche Chancen und Risiken gibt es für das Projekt und was kann dann dazu getan werden?
*Welche Methode soll zum Einsatz kommen?
*Wie soll die Prozesshierarchie grundsätzlich aussehen?
*Welche Standard werden benötigt?
*Welches Werkzeug soll verwendet werden?

=== 12.1 Einflussfaktoren ===

Die Einflussfaktoren müssen mit Sorgfalt berücksichtigt werden:

*'''Auslöser''': Welche Umstände haben zum Projekt geführt?
*'''Zielsetzung''': Was wird angestrebt? Woran ist der erfolgreiche Abschluss sichtbar?
*'''Anwendungsformen''': Wie sollen die Prozessmodelle verwendet werden?
*'''Risiken''': Welche Risiken sind erkennbar welche das Projekt gefärden können?

Mögliche Auslöser für eine prozessorientierte Reorganisation:

[[Image:Auslöser.jpg]]

'''Ziele der Prozessmodellierung'''

Ziele müssen schriftlich festgehalten werden. Von ihnen hängt ab welche Prozesse in welcher Reihenfolge modelliert werden und wie detailliert erhoben und dokumentiert werden soll

Mögliche Ziele:
*Erhöhung Kuzu durch Ausrichtung der Aktivitäten auf den Kunden.
*gemeinsames betriebliches Verständnis und dadurch verbesserte Kommunikation
*Optimierung der Geschäftsabläufe
*Erhöhung der Flexibilität bei Marktveränderungen
*Klare Zuteilung von Verantwortlichkeiten
*Prozess-Sicht bei den Mitarbeitern fördern
*Verbesserung der Mitarbeitermotivation durch Delegation von Entscheidungen und Aufgaben an Prozessteams

'''Zielgruppe und Anwendungszweck'''

Wer braucht Prozessmodelle und zu welchem Zweck?
*Hängt von der Art der Verwendung ab und muss deshalb in der Vorbereitungsphase geklärt werden.
*wenn nur eine Doku erstellt werden soll, genügen grobe Ablaufdarstellung.
*Wenn die Modelle für eine Workflow-managementsystem verwendet werden, müsse die Prozesse sehr detailliert dargestellt werden.

Im Übrigen kann es für den Projekterfolg und das interne Marketing von Vorteil sein, wenn mehrere Anwendungsarten gefunden werden können. Beispiele:

*Organisationsdokumentation
*Prozessorientiere Reorganisation
*Einführung eines Qualitätsmanagementsystem
*Qualitäts Zertifizierung (z.B. nach ISO 9000:2000)
*TQM-Assessment (z.B. nach EFQM)
*Prozessoptimierung
*Prozesskostenrechnung
*Benchmarking (Vergleich mit gleichartigen Organisationen)
*Prozessorientiertes Wissensmanagement (KM = Knowledge Management)

Informatik-orientierte Art der Anwendung
*Auswahl und Customizing von ERSP Software
*Ermittlung der Anforderungen für die Entwicklung einer Applikation
*Spezifikation von Workflows für den Einsatz eine sWFMS

'''Probleme bei der Prozessmodellierung'''

*Es gibt keine anerkannten Standards für die Prozessmodellierung.
*Es gibt keine allgemein gültige Vorgehensweise
*Es gibt keine Standars bei den Werkzeugen
*Es kann häufig nicht gesagt werden ob ein Modell richtig oder falsch ist.

je nach Verwendung, Philosophie, Zielgruppe muss das optimalste verwendet werden.

'''Chancen der Prozessmodellierung'''

*Trotz der genannten Probleme ist die Prozessmodellierung zu einer weltweit akzeptierten Praxis geworden.
[[Image:Chancen Prozessmodellierung.jpg]]

'''Risiken der Prozessmodellierung'''

*Jedes Projekt ist mit Risiken behaftet
*Es ist Aufgabe des PL am Anfang des Projektes die Risiken zu identifizieren.
*Risiken müssen gewichtet und wenn nötig Gegenmassnahmen bestimmt werden.

Wichtigster Erfolgsfaktor des Risikomanagements ist die offenen Kommunikation über Risiken und Massnahmen

Mögliche Risiken
*Mangelnde Unterstützung durch das Management
*Mangelnde Unterstützung durch die Mitarbeiter
*Widerstand beim Personal wegen Angst vor Veränderungen
*Mangelnde Verfügbarkeit von Fachexperten aus dem Betrieb

präventive Gegenmassnahmen:
*Frühzeitige Information über die Zielsetzung
*Projektmarketing-Massnahmen
*Mitarbeiter einbeziehen
*Sichtbares Engagement der GL
*Team Coaching
*Frühzeitige Planung von Vertretern der Fachexperten

== 13 Projekt abwickeln ==

*Das Modellierungsprojekt ist ein Projekt wie jedes anderen
*Es muss geplant, überprüft und budgetiert werden.
*Es muss ein Projektantrag mit klaren Zielsetzungen und ausreichender Begründung gestellt werden
*Es müssen Verantwortlichkeiten und Rollen verteilt werden.

=== 13.1 Projektphasen ===

'''Projektphasen bei der GPO'''
'''Vorstudie (Vorbereitung)'''
*festlegen Modellierungsgegenstand
*Aufnahme und Analyse der Anforderungen (Was)
*Festlegen der Zielsetzung
*Identifikation der Risiken
*Festlegen der Methode und Tools (Wie)
*Festlegen des Detaillierungsgrades
*Entwerfen des Rahmenmodells

'''Ist-Modellierung Ist-Analyse'''
*Erhebung der relevanten Informationen
*Aktuellen Stand der Abläufe dokumentieren
*Analyse der Schwachstellen
*Ermitteln von Verbesserungspotenzialen

'''Soll-Modellierung'''
*Entwickeln und Modellieren der neuen Abläufe
*Prüfen der neuen Abläufe
*Erarbeiten der neuen Aufbauorganisation
*definition der Anforderung an IT

'''Implementation / Roll-out'''
*Umsetzung der erarbeiteten Prozessverbesserungen
*Umsetzung der neuen Aufbauorganisation
*Information und Ausbildung der betroffenen Mitarbeiter
*Entwicklung / Customizing / Anpassung und Einführung der Software

'''Projektphasen beim BPR'''
*Vorstudie
*Makro-Entwurf
*Mikro-Entwurf

=== 13.2 Projektorganisation ===

'''Rollen'''
*Projektleiter
*Projektlenkungsausschuss. Überprüft des Projektvorschritts. Entscheiden über go/no-go. Treffen von Sachentscheidungen zum Projekt.
*Fachexperte
*Methodenexperte
*Modellierer
*Toolexperte
*Prozessverantwortliche

== 14 Qualität sichern ==

*zentrale Ergebnisse sind die Prozessmodelle und Dokumente
*um die Qualität sicherzustellen müssen Qualitätskriterien bestimmt und inhaltliche und formale Reviews durchgeführt werden.

=== 14.1 Qualitätskriterien ===

Die '''Grundsätze ordnungsgemässer Modellierung (GoM''') sind ein Versuch allgemein gültige Qualitätskriterien für Modell zu definieren.

'''Grundsatz der Richtigkeit'''
Voraussetzung für ein qualitativ hochwertiges Modell ist, dass es den zu repräsentierenden Sachverhalt korrekt wiedergibt. Dieser Aspekt kennzeichnet die semantische Richtigkeit. Hierbei ist die Richtigkeit von Modellen grundsätzlich nicht beweisbar , sondern ergibt sich aus dem Konsens der Fach- und Methodenexperten, die ein Modell als zutreffend erachten. Von der semantischen Richtigkeit ist die syntaktische Richtigkeit abzugrenzen, welche die Einhaltung der ggf. individuell definierten Notationsregeln beschreibt.

'''Grundsatz der Relevanz'''
Es sollen nur die Sachverhalte modelliert werden, die für den zu Grunde liegenden Modellierungszweck relevant sind. Um das beurteilen zu können, müssen die Ziele der Modellierung expliziert werden. Anhand der expliziten Modellierungsziele können Entscheidungen über das Abstraktionsniveau der darzustellenden Sachverhalte sowie der zu verwendenden Modellierungstechniken getroffen werden. Der Grundsatz der Relevanz ist ausserdem für die Entwicklung zweckadäquater Modellierungstechniken hilfreich.

'''Grundsatz der Wirtschaftlichkeit'''
Intention des Grundsatzes der Wirtschaftlichkeit ist es, sicherzustellen, dass die Modellierungsaktivitäten in einem angemessenen Kosten-Nutzen-Verhältnis zueinander stehen. Es ist zu beachten, dass die Modellierungskosten den eigentlich verfolgten Nutzen der entstehenden Modelle nicht überkompensieren. Die wirtschaftliche Modellerstellung kann bspw. durch die Nutzung von Referenzmodellen gefördert werden.

'''Grundsatz der Klarheit'''
Der Grundsatz der Klarheit trägt dem Tatbestand Rechnung, dass ein Modell nur von Nutzen ist, wenn es vom Adressaten auch verstanden wird. Abhängig vom Modellnutzer hat ein Modell einen adäquaten Grad an intuitiver Lesbarkeit aufzuweisen. So sind einerseits die Modellierungstechniken an sich nutzeradäquat auszuwählen und andererseits die Modelle mit Hilfe der Techniken möglichst klar und lesbar darzustellen.

'''Grundsatz der Vergleichbarkeit'''
Der Grundsatz der Vergleichbarkeit wird als Ziel formuliert, weil in realen Anwendungssituationen ggf. mehrere Modelle nebeneinander existieren, die vergleichbar sein müssen. Besondere Bedeutung kommt aus betriebswirtschaftlicher Sicht dabei dem Vergleich von Ist- und Sollmodellen zu, damit aus den Modellen Gestaltungsempfehlungen abgeleitet werden können. Daneben sind Modelle vergleichbar zu gestalten, die mit unterschiedlichen Modellierungstechniken erstellt worden sind. Der Grundsatz der Vergleichbarkeit zielt auf den semantischen Vergleich zweier Modelle ab, d. h. es sind die mit zwei Modellen beschriebenen Inhalte hinsichtlich ihrer Deckungsgleichheit zu untersuchen.

'''Grundsatz des systematischen Aufbaus'''
Dieser Grundsatz hat seine Notwendigkeit in der Darstellung eines Sachverhalts aus unterschiedlichen Sichten, die zur Reduktion dessen Komplexität gebildet werden. Bei der Modellierung von Informationssystemen werden Daten-, Funktions-, Organisations- und Steuerungssicht oder die Struktur- und die Verhaltenssicht unterschieden. Mit dem Grundsatz des systematischen Aufbaus wird eine sichtenübergreifende, Aspekte einbeziehende Modellerstellung gefordert. Dieses Ziel wird zum einen mit einem sichtenübergreifenden Metamodell gefördert, das den Zusammenhang zwischen den unterschiedlichen Sprachkonstrukten herstellt. Zum anderen ist auch für den Modellinhalt eine konsistente sichtenübergreifende Modellierung zu fordern.

=== 14.2 Modellqualität überprüfen ===

Um sicherzustellen, dass die Modelle alle wesentlichen Informationen erhalten, empfiehlt es sich eine Checkliste zu verwenden. Diese könnte wie folgt aussehen:

*Werden die prozessauslösenden OE/Kunden konkrete bzw. in Ihrer Rolle genannt?
*Sind die Empfänger/Kunden konkret bzw.über ihrer Rollen identifiziert?
*Ist das Startereignis so formuliert, dass dass der relevante Bginn des Prozesses eindeutig feststeht?
*Ist der Input der Prozesse beschrieben?
*Ist der Prozess mit einer ID beschrieben (eindeutig identifierbar)
*Output festgelegt?
*Ist prozessende durch ein Endereignis fetgelegt?

Formale Kriterien:
*richtiger Modelltyp verwendet?
*richtige Objekte und Beziehungen verwendet?
*Objekte richtig benannt?
*Notation korrekt angewendet?
Generell muss geprüft werden ob die in den Richtlinien (Konventionen) festgeschriebenen Regeln eingehalten wurden.

Inhaltliche Prüfung:
*Ist das Modell vollständig?
*klar und verständlich?
*stimmt der Ablauf mitder realität überein?
*sind alel Informationen relevant?
*richtige OE zugeordnet?
*richtige Sachmittel/Applikationen zugeordnet?
*Detaillierungsgrad angemeesen gewählt?
*Schnittstellen richtig angelegt?

Informatiker FA M227 Zusammenfassung

2019-08-01T13:20:23Z

Christian: Created page with "= Der Testprozess = == Welche Standards fördern die Softwarequalität == *ISO 12207 Rahmen für Beschaffung, Lieferung, Entwicklung, Betrieb, Wartung) *Capability Maturity..."

= Der Testprozess =

== Welche Standards fördern die Softwarequalität ==

*ISO 12207 Rahmen für Beschaffung, Lieferung, Entwicklung, Betrieb, Wartung)
*Capability Maturity Model (CMM). Fünf Reifegrad-Stufen. Initialier Prozess, Wiederholbarer Prozess, Definierter prozess, Gesteuerter propzess, Optimierter Prozess
*ISA 15504 Kombination aus ISO 12205 und CMM
*Test Maturity Model (TMM). Fünf Stufen des Reifemodells: Unsystematisch, organisiert, Kostensenkend, Systematisch, Optimiert.

[[Image:Beziehungen-Testprozess.gif]]

=== Beziehungen zur Qualitätssicherung ===
Die Abteilung "Qualitätssicherung" erarbeitet Qualitätstandards für das gesamte Unternehmen. Die Qualitätsrichtlinien werden im '''QS-Plan''' niedergeschrieben und sind verbindliche Rahmenbedingungen. Folgende zwei QS-Massnahmen werden grundsätzlich vorgeschlagen:

'''Konstruktive QS-Massnahmen:'''
*Qualität wird bereits beim Erstellen des Systems eingebracht.
*durh Vorgaben, Sprachen, Tools, organisatorische Regelungen, Standards, Checklisten

'''Analytische QS-Massnahmen'''
*überprüfen des erstellten Systems
*Verifizieren von Dokumenten
*Den Anforderungen gegenüber stellen.

===Beziehungen zum Projektmanagement===
*Projekt innerhalb vorgegebener Zeit, den budgetierten Kosten und der gewünschten Qualität abliefern
*PL gibt '''Soll-Termine''' und Meilensteine vor
*PL gibt auch '''Soll-Kosten''' vor welche als Input für den '''Testplan''' dienen.
*PL gibt Akzeptanzkriterien vor. Diese fliessen in den Testentwurf.

===Beziehung zu Systementwicklung===
*Softwareentwicklungsprozess liefert zu prüfende Objekte
*Die Softwareentwicklung bearbeitet die erstellten Problemmeldungen
*Die QS Aktivitäten verifizieren die Artefakte (Verifikation und Validierung)

'''Testen im Phasenmodell'''
*Phasenmodel: Fachkonzept, DV-Konzept, Realisierung, Testphase, Einführung
*In der Phase "Realisierung" findet die Codeinstpektion und die Unit-Tests statt.

'''V-Modell'''
*weit verbreitetes Vorgehensmodell
*Bewusste Genüberstellung der konstruktiven zu den prüfenden Aktivitäten

[[Image:V-Modell.gif]]

'''Testprozess im Rational Unified Process'''
*de-facto Standard in der objektorientierten Systementwicklung

[[Image:Rup.gif]]

'''Testen im Extreme Programming (XP)'''
*Einfaches Prozessmodell
*Softwaretests haben zentrale Bedeutung

[[Image:ExtremeProgramming.gif]]

===Beziehung zum Beschaffungsprozess===
*Im Gegensatz zum Systementwicklungsprozess wird das zu prüfende Objekte nicht selbst hergestellt, sonder eingekauft.
*Es sind Abnahmetests vorzusehen
*Die Kriterien sind im Voraus im Pflichtenheft sauber zu definieren

= IT-Qualitätssystem =

[[Image:IT-QS.gif]]

Ziel eines IT-Systems ist es während der Betriebsphase den geplanten Nutzen für das Unternehmen zu erbringen. In einem verbindlichen QS-Plan werden zwei Arten von Qualitätssicherungs-Massnahmen unterschieden:

*Konstruktive QS-Massnahmen (Vorgaben, Sprachen, Tools, organisatorische Regelungen, Standards, Checklisten
*Analytische QS-Massnahmen: überprüfen des erstellten Systems, Verifizieren von Dokumenten, den Anforderungen gegenüberstellen.

== Welches sind die Prüfobjekte ==
*Anforderungsspezifikation (Use-Case-Modelle, Prozessmodelle, Datenmodelle etc.)
*Design(Eingabemasken, Architektur, Prozessbeschreibung, Reports, etc.)
*Sourcecode
*Lauffähige Anwendung inkl. Handbücher und Installationsanweisungen
*Betriebs- und Systemsoftware
*DBMS
*Hardware
*Netzwerk

== Welche Qualitätsdimensionen weist ein IT-System auf ==
*Funktionalität. Aufgabenangemessenheit, Genauigkeit, korrekt, fehlerfrei, Verknüpfbarkeit mit anderen Anwendungen, Konformität z.B. zum Gesetz oder CI.
*Zuverlässigkeit. Robustheit, eine gewisse Reife, Fehlertoleranz, Wiederherstellbarkeit. Wird anhand Anzahl der Systemausfälle in einer bestimmten Zeitperiode gemessen.
*Benutzbarkeit. Ergonomie, Anwenderfreundlich, Bedienbarkeit, Erlernbarkeit, GUI-Standards.
*Effizienz. Antwortzeiten, Lastverhalten, Batchverarbeitung, Datendurchsatz, Skalierbarkeit
*Wartbarkeit. Unterbruchfreien Betrieb sicherstellen. Erweiterbarkeit, Parametrierung, Analysierbarkeit (für Erweiterung), Prüfbarkeit.
*Übetragbarkeit. Installierbarkeit (gemäss regeln des OS), Deinstallierbarkeit, Konformität, Austauschbarkeit, OS-Portierbarkeit.

== Qualitätsmerkmale messen ==
*Für jedes Messverfahren muss ein Messverfahren festgelegt werden.
*Klar definierte Messbedingungen
*Messskala und Grenzwerte festlegen

[[Image:QS-messen.gif]]

= Teststrategie =
*Unternehmen werden von eine Vision getragen
*Aus der Vision wird die Unternehmensstrategie abgeleitet
*Darunter die IT-Strategie
*Das Qualitätsmanagement (QM) hat die Aufgabe die Qualität in allen Bereichen des Unternehmens zu erhalten bzw. zu steigern. Dort wird unter anderem der QS-Plan erstellt welcher die QS-Organisation regelt, die Aufgaben, Verantwortlichkeiten, und Schnittstellen vorgibt.
*Der QS-Plan beinhaltet weiter Methoden, Techniken, Richtlinien sowie Kontrollmassnahmen.
*In die Teststrategie fliessen die Vorgaben der IT-Strategie und des QS-Plan ein.

Die Testpolitik regelt grundlegende Prinzipien zum Thema "Prüfen und TEsten"

*Definition und Bedeutung von Prüfen und Testen
*Definition des zu erreichenden Qualitätsniveaus
*Definition des Testprozesses und Zusammenspiel mit Unternehmensprozessen
*Metrik für Messungen
*Ansatz zur Optimierung des Testprozesses (z.B. TMM)

Das Testhandbug regelt dagegen konkrete Aspekte des Testprozesses:
*Projektübergreifende Richtlinien und Methodiken
*Darstellung der Risiken und Massnahmen
*Aufzuziehende Testorganisation
*Richtlinien Testumgebung (Infrastruktur, Testwerkzeuge)
*Workflow des Testprozesses
*Einsatz von Testmethoden und Testarten
*Firmeninternes Glossar
*Vorlagen für Test- und Berichtsdokumente

[[Image:Teststrategie.gif]]

== Welche Grundsätze beeinflussen des Testprozess? ==
*Alle menschlichen Erzeugnisse weisen Fehler auf
*Die Abwesenheit von Fehlern kann ab einer bestimmten Komplexität nur noch mit einem extrem Aufwand nachgewiesen werden.
*Der '''Summationseffekt''' bildet ein weiteres Problem: Fehler die z.B. in der Analysephase entstehen, führen zu einem mangelhaftem SW-Entwurf, der sich dann bei der Implementation fortsetzt.
*'''Faustregel: Je früher sich ein Fehler einschleicht und je später er entdeckt wird, desto teurer wird dessen Behebung'''
*Ein Entwickler sollte nicht sein eigenes Programm testen. (gleiche Überlegungsfehler)
*Die Tester müssen das Auffinden von Fehlern als Erfolg betrachten. (Wettbewerb fördern)
*'''Pareto-Prinzip''': 80-zu-20-Regel, besagt, dass 80 % der Ergebnisse in 20 % der Gesamtzeit eines Projekts erreicht werden. Die verbleibenden 20 % der Ergebnisse verursachen die meiste Arbeit.
*Wo ein Fehler gefunden wird, ist es wahrscheinlich, dass noch weitere Fehler existieren.
*implizite Qualitätsanforderungen: Nicht alle Qualitätsmerkmale lassen sich explizit (schriftlich) festhalten. Das Einhalten bestimmter GUI-regelen wird z.B. automatisch vorausgesetzt.
*Ein Benutzer darf in keine Falle laufen. Ein Benutzer darf aufgrund einer Fehleingabe keine Daten und/oder kostbare Zeit verlieren.

== Welches ist das optimal Testvorgehen ==
*ein inkrementelles Vorgehen ist oft besser als ein Big Bang
*Test soll parallel zur Systementwicklung ablaufen
*Die Integrationstests können dadurch in einem frühen Stadium vorgenommen werden.

=== Top-Down Verfahren ===
*eignet sich vor allem für ein frühes Stadium
*Mit Hilfe eines Prototyps kann das Aussehen und die Abläufe mit dem Auftraggeber besprochen werden.
*Noch nicht entwickelte Module werden durch Stubs (Dummies, Testrümpfe) ersetzt.
*Bei diesem Verfahren stehen die einzelnen Anwendungsfälle beim Testen im Vordergrund.

=== Bottom-Up Verfahren ===
*bewährt sich im fortgeschrittenen Stadium
*die entwickelten Module werden im Detail getestet
*die aufrufende Software wird durch "Drivers" simuliert.
*In diesem verfahren geht man von der bestehenden Funktionalität aus.

Manchmal lässt sich die Reihenfolge der zu entwickelnden Komponenten nicht streng nach Bottom-Up oder Top-Down realisieren. Dann werden die Module '''ad hoc''' nach deren Fertigstellung integriert. Eine andere Variante ist die bewusste Priosierung der komplexen und risikoreichen Module: '''hardest first'''.

== Wie werden die Testfälle ermittelt? ==

=== Methodisches versus exploratives Vorgehen ===

Vorteile methodisches Vorgehen:
*Abdeckung der Fälle berechenbar
*Testfortschritt messbar
*Deshalb für kritische Systeme weitgehend methodisch vorgehen.

exploratives Vorgehen:
*intuitive Vorgehensweise
*Testen methodisch nicht erfassten Fälle
*Aufgrund persönlicher Erfahrung werden mögliche Fehler erahnt.
*unübliche Konstellationen können getestet werden
*Beim ad hoc Test werden die Testfälle spontan ermittelt und ausgeführt
*Beim unsymetrischen Test wird ohne im Voraus definiertes System getestet
*Beim Zufallstest werden Testfälle zufällig ausgewählt
*Beim Guerilla-Testen testet man unerlaubtes. Falsche Eingaben, alle Tasten gleichzeitig, Strom abstellen etc.
*Darf nicht mit chaotischem Testen verwechselt werden.
*Für Frontends gut geeignet.

Explorative Tests sind vor allem bei System- und Abnahmetests zu empfehlen und haben folgende Vorteile:
*Kann grosse Zeitersparnisse mit sich bringen.
*Erfahrung des Testers kann voll genutzt werden.
*Hohe Flexibilität während des Testens
*Systemfunktion kann während des Testens erforscht werden, was zu neuen, vorher nicht erkennbaren, Testfällen führen kann.

=== Methodische Testfallermittlung ===

Je nach Phase werden schwerpunktmässig andere Testmethoden ausgewählt:

*Modul- und Unittest: Whitebox- und/oder Blackboxtest
*Integrationstest: Greybox-Test
*Systemtest: Blackbox-Test

[[Image:Testmethoden.gif]]

'''Whitebox-Test''' (strukturelles Testverfahren)
*setzt detaillierte Kenntnisse des Systems voraus.
*Anhand des Sourcecodes und den Anforderungen wird gezielt getestet
*Weil beim erstellen Sourcecode Teile noch fehlen können, müssen die Detailspezifikationen für das Testen ebenfalls beigezogen werden.
*Die Testabdeckung zeigt anhand der inneren Struktur den prozentuellen Abdeckungsgrad. (Welche Programmpfade wurden schon getestet). Dazu können Coverage-Monitore eingesetzt werden.

[[Image:Testabdeckungsgrade.gif]]

Beispiel einer Adeckungsanalyse:

[[Image:Abdeckungsanalyse.gif]]

'''Greybox-Test'''
*wird vor allem beim Integrationstest eingesetzt
*Die Tester kennen den Source-Code der einzelnen Module nicht. Sie betrachten die einzelnen Programme also im Blackbox-Verfahren.
*Das Zusammenspiel und die Ablauffolge der einzelnen KOmponenten ist aber bekannt. Die Testfallauswahl erfolgt somit im Whitebox-Verfahren.
*Es wird somit geprüft ob alle Komponenten mindestens einmal getestet werden. (Komponentenabdeckung)
*Zeitreihen können eine wichtige Rolle spielen (z.B. mehrere Änderungen an einer Adresse)

'''Blackbox-Test'''
*Wird vor allem beim Systemtest angewendet
*Die Tester kümmern sich nicht um die innere Struktur.
*Getestet wird das erwartete Verhalten und die definierten Schnittstellen
*wird deshalb funktionelles Testverfahren genannt
*Ausgangsbasis: Anwendungsfälle (Use Cases), Anforderungen aus dem Pflichtenheft und dem Systementwurf.

Testfälle werden auf Grund von '''Äquivalenzklassen''' und '''Grenzwertanalysen''' gebildet

*Äquivalenzklassen = gleichartiges Verhalten
*Es werden alle Äquivalenzklassen ermittelt und je ein Vertreter der Klassen gibt einen Testfall der alle anderen möglichen Fälle der anderen Klassen vertritt.

In der '''Grenzwertanalys''' werden alle Fälle bei Wertübergängen erfasst und die Tests konzentrieren sich auf diese Übergänge in der Annahme, dass sich die Werte dazwischen gleich verhalten.

Beispiel einer '''Äquivalenzklassenbildung''':

[[Image:Aequivalenzklassenbildung.gif]]

Beispiel einer '''Grenzwertanalyse''':

[[Image:Grenzwertanalyse.gif]]

=== Zustandsbezogene Tests ===

*gehört zum Blackbox-Testing
*Es gibt Programmobjekte welche sich bei mehrmaligem Aufruf unterschiedlich verhalten (je nach State)
*Die Aktion hängt von der Historie ab
*Dies wird in einem Zustandsdiagramm dargestellt
*Aufgrund der möglichen Zustände und Übergänge wird ein Übergangsbaum erstellt.

Die folgende Komponenten steuert die Zutrittskontrolle eines Unternehmens. Die maximal Anzahl der Mitarbeiter die Zutritt haben, wird dem Personalbestand entnommen. Je nach Zustand wird der Zutritt gewährt oder abgelehnt.

Beispiel eines '''Zustandsdiagramm''':

[[Image:Zustandsdiagramm.gif]]

'''Übergangsbaum''':

[[Image:Uebergangsbaum.gif]]

=== Diversifizierendes Testen ===

Back-to-Back-Test
*zwei Programmierer erhalten die selben Spezifikation
*beide entwickeln Module
*beide Module werden getestet
*wenn beide Module das selbe Resultat liefern kann man davon ausgehen, dass die getesteten Fälle korrekt sind.

Mutationentest
*In einer Version wird bewusst ein Fehler oder eine Erweiterung eingebaut
*Beide Version werden gleich getestet
*Wenn sich sich identisch verhalten, kann man davon ausgehen, dass ein Fehler existiert.

=== Risikoorientiertes Vorgehen ===
*Oft fehlt die Zeit um alles ausgiebig zu testen
*Deshalb müssen die Objekte in Risikokategorien eingeteilt werden.
*Das '''Risiko''' entspricht der Eintrittswahrscheinlichkeit multipliziert mit dem finanziellen Schadensausmass

Externe Risiken (nicht beeinflussbar):
*Naturereignisse
*Politische, gesetzliche Veränderungen
*Gesellschaftliche Veränderungen
*Marktwirtschaftliche Veränderungen

Strategische Risiken (schwer beeinflussbar)
*Organisatorische Veränderungen
*Finanzielle Risiken

Projektrisiken (relativ gut beeinflussbar)
*Vertragserfüllung
*Mitarbeiter
*Termine
*Synchronisation bzw. Abhängigkeiten zu anderen Tätigkeiten
*Ressourcen
*Kommunikation

Produktrisiken (relativ gut beeinflussbar):
*Funktionale Fehler
*Akzeptanz durch die Benutzer
*Systemintegration und -konfiguration
*Mengen (Datenmenge, Anzahl Benutzer, Anzahl Transaktionen)
*Image des Unternehmens
*Sicherheit des Systems

Beim risikoorientierten Vorgehen wird jedem Objekt eine Kritikalität zugewiesen. Z.B.
*'''Sehr''' hoch: gefährdet Unternehmen oder sogar Leben
*'''Hoch''': kann zu massiven materiellen oder immateriellen Schäden führen.
*'''Mittel''': kann zu kalkulierbaren Schäden führen
*'''Niedrig''': kann zu geringen Schäden führen.

= Testarten =

*Beim statischen Prüfverfahren werden die einzelne Artefakte (z.B. Anforderungsdokument, Analyse-, Designmodell, SourceCode, tech Doku) genauer unter die Lupe genommen.
*Beim dynamischen Prüfverfahren (Testen im eigentlichen Sinn) werden Systems ausgeführt und Fehlerwirkungen nachgewiesen. Anhand der Resultate suchen die Entwickler danach die Fehler.

== Statische Prüfverfahren ==

*QS-Überwachung
*Prüfung primär durch Menschen
*Es gibt aber auch unterstützende Tools die den Code oder die Dokumente analysiseren.
*Hauptziel: Fehler in einer möglichst frühen Phase erkennen und beheben.

=== Informelles Review ===
*wird nicht angeordnet
*Der Autor wird selber aktiv und bitte Arbeitskollegen zu einer ad hoc Sitzung.
*Eine einfachere Variante ist die die Zustellung mit der Bitte zu einer Stellungsnamen (mit Termin)
*Bei '''einem Peer Rating''' sind die Projektmitarbeiter örtliche getrennt. Das prüfobjekt wird dann mit einer Checkliste und einem Beurteilungsbogen zugestellt.

=== Walktrough ===
*mit einem mehr oder weniger struktierten Vorgehen wird die Qualität des Prüfobjektes verbessert.
*in einer entspannten Atmosphäre
*möglichst viele Fehler oder Regelverstösse finden.
*miteinander eine gute Lösung finden
*mit einer '''prüfobjektorientierter''' Checkliste kann die Effizienz markant gesteigert werden.

=== Technisches Review ===
*formelle Prüfungsart
*werden von PL angeordnet
*Moderator stellt Objekt mehreren Experten zur Verfügung
*In einer gemeinsamen Sitzung wird beurteilt.
*Der Autor beantwortet nur gestellt Frage oder klärt Missverständnisse, hält sich aber sonst zurück.
*Es wird ein Protokoll geführt. (evtl. durch den Autor)
*Mögliche Beschlüsse: Freigabe, Freigabe mit Vorbehalt, Zurückweisung.

=== Inspektion ===
*Schwerpunkt liegt bei der Überprüfung klar definierter Anforderungen (Codekonventionen, Ressourcengebrauch, Schnittstellenkonformität)
*ist ebenfalls formelle Prüfung
*der Ablauf entspricht dem beim technischen Review

=== Audit ===
*wird i.d.R. vom Management angeordnet
*ein Gegenstand wird auf die Erfüllung externer Anforderungen untersucht
*geschieht im Rahmen eines '''Assesements'''.
*kann sowowohl Dokumentenstudium wie ciah Sitzungen und Interviews umfassen.
*wird durch einen Assementbericht abgeschlossen. Die gibt eine Beurteilung des Ist-Zustandes und eine Empfehlung für den Soll-Zustand ab.

== Dynamische Prüfverfahren ==

*Tests im eigentliche Sinne
*Lauffähige Systeme werden gegenüber den Erwartungen validiert.
*Je nach Phase werden steten andere Testarten zur Verfügung

[[Image:V-Modell.gif]]

=== Testarten, die statische Prüfverfahren unterstützen ===
*jede Testart lässt sich einer Teststufe zuordnen
*Die Planung des durchzuführenden Testarten wird deshalb '''Teststufenplan''' genannt.
*'''Testaktivitäten''' unterstützen die statischen Prüfverfahren
*In der Analyse- und Entwurfsphase werden '''Prototypen''' entwickelt.
*Der '''Prototyptest''' erfolgt in einem '''Review'''.
*Wird SW nicht selber entwickelt, wird dies über einen Evaluationsprozess. Während der Auswahl erfolgt ein '''Proof-of-Concept'''. Dabei führt der Lieferant eine Testinstallation beim Kunden durch.

=== Unit-Tests ===
*Während der Implementation testen Entwickler fortlaufend. Diese Tests sind Bestandteil des SW-Entwicklungsprozesses.
*Der Unit-Test ist jedoch Bestandteil, des Testprozesses
*Hier werden Bestandteile als separate "Units" getestet (Funktionalität, Schnittstellen)
*Mit Negativtests (Eingaben welche fehler verursachen müssen) wird Robustheit getestet.
*Zeitverhalten wird geprüft.
*Überprüfung der Wartbarkeit mittels Review oder Inspektion.
*Unit-Tests können mit der White- oder Blackboxmethode durchgeführt werden.
*Testtreiber und Analysatoren unterstützen den Tester bei der Automatisierung und der Auswertung.

Bezeichnungen für Unit-Test (je nach Prüfobjekt)
*Modultest
*Programmtest
*Klassentest
*Komponententest
*Datenbanktest

=== Integrationstest ===
*Das Zusammenspiel der einzelnen Komponenten und die Schnittstellen zu dem Umsystemen wird geprüft.
*Die einzelnen Schichten (n-tier) werden geprüft.
*Danach dir Schnittstellen zu den anderen Schichten.
*Hardwarekompatiblität und Betriebssystemkompatibilität wird geprüft.
*Auch das Netzwerk ergibt eine breite Palette an Testfällen

Mit dem Integrationstest soll nicht gewartet werden bis alle Unit-tests abgeschlossen sind.

=== Systemtest ===
*Nach dem Integrationstest folgt der Systemtest.
*Hier wird das ganze System getestet.
*Ziel ist es, die geforderte Systemqualität nachzuweisen

[[Image:Systemtest.gif]

Neben den eigentlichen Testspezialisten können auch andere Fachbereiche vertreten sein (Netzwerkspezialist, Systemspezialist, Andwende etc.)

'''Funktionstest'''
*sämtliche Anwendungsfälle (Use Cases) werden getestet.
*Vollständigkeit und Richtigkeit steht im Vordergrund

'''Benutzerbarkeitstest'''
*GUI-regeln werden geprüft
*sachlich logische und intuitive Benutzerführung
*einfache Erlernbarkeit
*Dokumentation
*kontextsensitive Hilfe

'''Installationstest'''
*verschiedene Betriebssystemvarianten
*Sprachen
*Installation muss automatisch ablaufen
*saubere Deinstallation
*Upgradeinstallationen

'''Zertifizierungstest / Kompatiblitätstest'''
Die Kompatiblität muss auf drei Ebenen sichergestellt werden
*Hardware und Netzwerk
*Betriebssoftware
*Andere veknüpfte Anwendungssoftware

Folgede Zertifizierungen sind denkbar:
*Hardware-Anbieter
*OS Anbieter
*Amtliche Stellen (z.B. SUVA)

'''Perfomancetest'''
*Beim '''Lasttest''' wird die Effizienz und Zuverlässigkeit geprüft. Systemlast wird simuliert. Antwortzeiten interessieren.
*Beim '''Stresstest''' wird die Systemlast bis zum Zusammenbruch erhöht. System muss wie erwartet reagieren (z.B. Meldungen auslösen und regulierende Massnahmen auslösen). Darf nicht kommentarlos zusammenbrechen.

'''Benchmark-Test'''
*genormte Messverfahren
*Kriterien werden miteinander verglichen

'''Katastrophentest'''
*Extremsituationen werden simuliert (Stromausfall, Disk-Crash, netzwerkausfall)
*Im Idealfall soll System automatisch wieder im letzten konsistenten Zustand anlaufen.
*Auch organisatorische und bauliche Massnahmen werden mit einbezogen (z.B. Feuerschutz)

'''Sicherheitstest'''
*Datensicherheit (keine Daten dürfen verloren gehen)
*Datenschutz
*Penterationtests
*Ethical Hacking (von innen, von aussen, angekündet, nicht angekündet, physischer Zugang, remote Zugang, Tarnen als Mitarbeiter)

=== Abnahmetest ===

*Beim Abnahmetest geht es um die Beurteilung aus Sicht es Kunden
*Ein erfolgreicher Abnahmetest entlastet das Entwicklungsteam und bestätigt, dass alle Anforderungen vollumfänglich erfüllt sind.

Varianten Abnahmetest:
*Test der vertraglichen vereinbarten Akzeptanz
*Test der Benutzerakzeptanz
*Test der Akzeptanz durch den Systembetreiber
*Verknüpfung des Abnahmetests mit einem Livetest.

Probleme bereiten iommer wieder nicht explizit erwähnte Anforderungen die sich aus Industriestandards oder Usanzen ergeben. Empfehlung: Solche Anforderungen immer explizit in den Vertrag nehmen.

=== Live-Test ===
*findet in der produktiven Umgebung statt
*erhöht die Sicherheit, dass die Anforderungen im produktiven Umfeld erfüllt werden.
*Live-test ist oft Abnahmetest.
*begrenzter Zeitrahmen

[[Image:Live-Test.gif]]

'''Parallebetrieb'''
*altes und neues System laufen eine bestimmte Zeit lang parallel
*resultate werden laufen verglichen
*aufwändiges System
*kann nur für kritische Projekte eingesetzt werden.

'''Pilotbetrieb'''
*ein Teilbereich eines Unternehmens arbeitet eine bestimmte Zeit lang auf dem neuen System. Die anderen auf dem alten
*Wenn Mängel auftreten wird nicht das komplette Unternehmen beeinträchtigt.
*Wenn sich das neues System bewährt, kann dieses für das ganze Unternehmen freigegeben werden.
*Dieses Verfahren kann nur eingesetzt werden wenn keine Integrationsschwierigkeiten mit den bestehenden Systen der anderen OE auftreten

'''Beta-Test-Phase'''
*hat sich bei Standardsoftware eingebürgert welche an ein breites Publikum verkauft wird.
*Benutzer melden sich meist freiwillig
*Das Risiko ist beim Tester
*Die Fehler werden beim SW-Hersteller gesammelt und jenachdem wird ein zweiter Beta oder Finalrelease herausgegeben.

=== Regressionstest ===
*Bei jeder Änderung des Systems besteht das Risiko von Sideeffects.
*Das Configmanagement regelt den Änderungs- und releaseprozess
*bevor ein neues Release freigegeben wird, mus sein Set von Tests durchgeführt werden.
*Diese Testwiederholung wird Regressionstest genannt.
*Diese sind i.d.R. risikoorientiert.
*hoher Automatisationsgrad
*Ein Subset der wichtigsten Tests wird '''Smoke-Test''' genannt und sollte vollautomatisch ablaufen.

= Testorganisation =

Damit Menschen effizient arbeiten können, müssen sie sich organisieren. Zwei Aspekte spielen eine Rolle:
*Aufbauorganisation
*(Prozessorganisation) Ablauforganisation

== Welche Rolle können Projektmitarbeiter im Testprozess übernehmen ==
*Die Testorganisation ist ein Teil der Projektorganisation
*Die Rollen sind in der Teststrategie zu definieren.
*Innerhalb eines Projektes werden den Rollen Personen zugeordnet.
*Eine Person kann mehrere Rollen haben
*Nicht in allen Projekten wird jede Rolle benötigt. Einen Restdesigner, Testmanager und mindestens ein tester werden aber immer benötigt.

[[Image:OrganigrammTestteam.gif]]

möglich Rollen mit ihren typischen Skills:

[[Image:TestSkills.gif]]

== Aus welchen Teilschritten besteht der Testprozess ==

*Der Test ist ein phasenübergreifende, nebenher laufender Prozess
*wird auch Testverfahren oder Testvorgehensweise genannt.
*ANSI/IEEE 829 definiert die einzelnen Phasen und die daraus resultierenden Dokumente

[[Image:ANSI IEE 829.gif]]

=== Test planen ===
*Der Testmanager erstellt parallel zum Design des Systems das Testkonzept (auch Testplan ider Prüfplan genannt). Wichtige Informationen aus den Anforderungen und dem Entwurf des neuen Systems fliessen in die Planung der zu testenden Funktionen.
*Grundlagen für den Testplan bilden der QS-Plan, die Teststrategie, die Anforderungs- und Entwurfsdokumente sowie der Projketplan.
*Für jedes Testobjekt wird der gewünschte minimale Qualitätsstandard definiert.(ohne Details)
*Aufbauorganisation wird anhand der notwendigen Ressourcen definiert und bei der PL beantragt.
*Restumgebung und Testwerkzeuge werden festgelegt und Beschaffung bzw. Bereitstellung beantragt.
*Ressourcen- und Zeitplan werden wenn möglich toolgestützt mit dem TL abgestimmt (z.B. MS Project)

=== Test entwerfen ===

*Anhand des Testplans und den Anforderungen erstellt der testdesigner die '''Testentwurfsspezifikation'''. Dies läuft paralell zu den Designarbeiten.
*Der Entwickler kann seine eigenen Unit-tests bereits darauf abstützen.
*Für jede zu testende Funktion gemäss Testplan wird das '''Testverfahren''' festgelegt
*Der testdesigner bestimmt die Testmethode.
*Daraus leitet er die Testfälle ab (ohne Details)
*Er kreiert auch einzelnen Testszenarien (zusammenhängende, logische Testfälle)
*Ein einzelnes Testdrehbuch handelt ein solches Testszenario ab.
*Auf Grund der Qualitätskriterien werden Pass- und Failkriterein festgelegt.

=== Test spezifizieren ===
*Auf Grund der im Testentwurf aufgeführten Testfälle spezifiziert der Testdesigner die Details der einzelnen Fälle.
*Ein Testfall ist eine Kombination von Eingabedaten, Bedingung und erwarteten Ausgaben.
*Die Vorbedingung und Abhängigkeiten sowie die nötige Testumgebung ist aufzuführen.
*Hinweis auf mögliche Automatisierung

=== Testprozedur erstellen ===
*Der Testdesigner erstelle pro Testseznario ein Testdrehbuch.
*Darin sind die zu testenden Fälle mit Sinn und Zweck aufgeführt.
*Ebenso sind sind die auszuführenden Schritte und die erwarteten resultate aufgeführt.

5.2.4

*Testengineer oder Testautomatisierer erstellen evtl. benötigte Automatisierungsscripts
*Deren Beschreibung kommen ins Testdrehbuch
*Die Automatisierungsscripts unterliegen dem Change- und Configmamanagement (Zuweisung zum richtigen Build)

=== Testumgebung aufbauen ===
*Der Testadministrator organisiert die Infrastruktur
*Entwicklungs- Test- und Produktivumgebung werden strickt getrennt.
*Evtl. sind auf Grund der Komplexität mehrere Testplattformen nötig.
*Testwerkzeuge müssen installiert werden.
*Benutzer- und deren Rechte definieren.
*Schulung der Tester (Testsoftware)
*Für die Unit- und Integrationstest ist das Testgeschirr zu installieren.
*Testgeschirr = Software zur Simulation aufrufender Programme.
*Testobjekte bereitstellen.

=== Test ausführen ===
*Tester nehmen ihre eigentliche Arbeit auf
*exploratives "spielen" wie auch schrittweises Durcharbeiten der vorgegebenen Szenarien
*Tester stützt sich primär auf Testdrehbuch
*Tester nimmt ergänzend die Testfallbeschreibung und die Testentwurfsspezifikation zur Hand.
*Neben des Tests ist das Protokollieren die wichtigste Tätigkeit
*Im Protokoll enthalten: Welche Testschritte, welche Resultate, eventuelle Änderungen an der Testumgebung.
*Aufgetretene Probleme sind als Problemmeldung für die Entwickler nachvollziehbar zu dokumentieren.
*Vermutungen können vermerkt werden.
*Fehlersuche ist aber Aufgabe des Entwicklers (nicht Tester)

=== Test auswerten ===
*Testmanager fast Resultate im Testprotokoll zusammen
*Gemäss QS-Plan geforderte Dokumente werden erstellt (Testmanager)
*Systeme welche einen Test nicht bestanden haben, werden der Entwicklung zurückgegeben.
*Wenn alle TEsts innerhalb einer Haupttestart (z.B. Unit-TEst, Integrationstest, Systemtest etc) bestanden sind, verfasst der Testmanager einen

Testabschlussbericht und gibt das System für die nächste Haupttestart frei.

== Wie läuft der Testzyklus ab ==
*Testprozess läuft nicht stur nach dargelegten Schritten ab
*Testplanung wird einmalig vorgenommen und danach bei Bedarf überarbeitet
*Die Testspezifikation wird während der Softwareentwurfsphase möglichst für alle Testarten komplett erstellt.
*Testumgebung wird ebenfalls einmalig aufgesetzt und schrittweise den Bedürfnissen angepasst

[[Image:Testzyklus.gif]]

*Fehlersuche und Fehlerbehebung sind keine eigentlichen Testtätigkeiten. Sie gehören aber eng zum Testen.
*Je nach Art des festgestellten Mangels findet eine Triage statt.
*Wenn Testdaten falsch sind, Probleme mit der Testumgebung existieren oder die Testwerkzeuge fehlerhaft sind wird die Umgebung angepasst und der Test wiederholt.
*Bei Implementierungsfehlern müssen entweder Anforderungen, das Design oder die entwickelte Komponente angepasst werden.
*Je nach Abhängigkeit müssen dadurch andere Testszenarien wiederholt werden (Sideeffects)
*Mögliche sind auch Benutzerfehler(Tester). Benutzer schulen, Doku anpassen.
*Beim Testen auftretende Wünsche müssen als Change Request (CR) behandelt werden. SOnst wird Projektplanung gefährdet.
*CR werden dem Change Management übergeben. DOrt wird entschieden ob und wann die Änderung einfliesst.

= Testdokumente =
*Erstellung der Testdokumente = wichtige Aufgabe des Testteams.
*Ansonsten tappen PL und Testmanager im Dunkeln
*Grosser Teil der Kommunikation zwischen PL und Testmanager erfolgt über Testplan und die darin definierten Testberichte
*Wenn die Testspezifikationen dem Entwickler abgegeben werden, ergibt dies einen positiven Effekt.
*Alle Dokumente sollten eine Identifikation enthalten und eine einer Projektablage zugänglich sein.

[[Image:Testdokumente.gif]]

== Wie ist Testkonzept aufgebaut ==

Ersteller = Testmanager. Inhalt:

*Einführung
*Zu testenden Komponenten
*Teststrategie
*Pass- und Failkriterien
*zu erstellende Dokumente
*Testumgebung
*Verantwortlichkeiten
*Testorganisation
*Zeitplan
*Risiken

== Wie ist die Testentwurfsspezifikation aufgebaut ==

Ersteller = Testdesigner. Inhalt:

*Testobjekte
*zu testende Funktionen
*Testverfahren
*Verweise auf Testfälle und Testdrehbücher
*Detaillierte Pass- und Failkriterien

== Aus welchen Elementen besteht der Testfall ==
Der Testfal ist Kombination aus Eingabe, Bedingung und erwarteter Ausgabe.Er besteht aus

*Testobjekt (Rererenzierung zum Testentwurf)
*Eingabedaten (z.b. Input-Tabelle, File-Share, Datenbank, Testtool, Bildschirmeingaben)
*Erwartete Ausgaben (Output-Tabelle, Files, Antwortzeiten, Ausdruck, Systemmeldungen, Rückgabewert)
*Notwendige Testumgebung
*Zu berücksichtigende Punkte

== Was beinhaltet das Testdrehbuch ==
Der Testdesigner notiert im Testdrehbuch wie ein Testszenario Schritt für Schritt getestet werden soll. Bereits bestehende Anweisungen aus der Testfallbeschreibung werden nur referenziert. Inhalt:

*Zielsetzung
*Voraussetzungen
*Einzelschritte des Tests (Vorbereitung, Start, Durchführung, Beobachtung, Abruch, Neustart, Stopp, Abschluss, Aufräumen, Unvorhergesehenes)
*Art und Weise der Loggführung ist festzulegen

= Testumgebung =

'''Begriffe''':
*'''Testgeschirr''': notwendige Instrumente und Tests durchzuführen
*'''Testbett''':: Bequeme und sachlogische Einbettung in die Systemumgebung
*'''Testrahmen''': organisatorische und teschnische Rahmenbedingungen

Folgendes muss bei der Testumgebung beachtet werden:
*Unterschiedliche Anforderungen
*Einfache Wiederholbarkeit
*Systematische Erfassung der Resultate
*Bequeme Auswertung

== Wie wird Testumgebung aufgebaut und betrieben ==
*frühzeitig planen
*wenn nötig über Evalutaionsprozess Teile beschaffen

'''Umgebungen immer sauber trennen'''

[[Image:Testumgebung.gif]]

=== Testumgebung beschaffen ===

*Anforderungen an die Testumgebung sind im Testplan festgehalten
*Frühzeitig eventuelle Beschaffung auslösen
*Ressourcen reservieren
*Die Auswahl der richtigen Automatisierungstools ist sehr wichtig. Deshalb genügend Zeit einplanen. Auch für Schulung.
*Der Tester muss geschult werden. Deshalb muss Testinfrastruktur vor den eigentlichen Tests bereitstehen.
*Der Testadministrator ist für die Koordination und den Auf- und Abbau der Testumgebung verantwortlich. Er ist auch Anpsrechpartner bei Schwierigkeiten.

=== Elemente der Testumgebung ===
*Die Elemente werden als Vorgaben im testplang festgehalten.
*Der Testmanager gibt dort die organisatoreischen und infrastrukturiellen Vorgaben an.
*Technische Merkmale in den Vorgaben sind hilfreich.

[[Image:Elemente Testumgebung.gif]]

=== Testumgebung verwalten ===

Je nach Einsatzgebiet ergeben sich mehrere Anforderungsdimensionen:

*Software-Releases welche für dei Wartung nicht gewährleistet werden muss.
*Unterschiedliche Betriebssysteme (z.B. alle Windows-Varianten, Unix, Linux etc.)
*Diverse DBMS (MS-SQL, Orcale, DB2)
*Länderspezifische Einstellungen
*verschiedenene Sprachversionen

Deshalb braucht es verschiednene Methoden und Techniken. Z.B.

*Unterschiedliche Systeme welche auf Grund der Namensgebung Aufschluss über die version geben.
*durchdachte Verzeichnissstruktur
*Disks clonen
*Arbeiten mit virtuellen Maschinen

Auf Grund der Komplexität ist die Testumgebung oft Teil des Konfigurationsmanagements.

== Wie können Tests automatisiert werden ==

*Ab einer bestimmten Kompleitätsstufe ind automatisierte Testwerkzeuge ein MUSS.
*z.B. Lasttests
*Bereits ab der dritten Testwiederholung loht sich ein Tooleinsatz
*CAST = Computer Aided Software Testing
*Die Tools sind jedcoh nur hilfrewich wenn sie in geschulten Händen und in geordneten Prozessen angewendet werden.

[[Image:TestTools.gif]]

=== Tools zur Prozzessunterstützung ===

'''Testmanagement-Software'''
*unverzichtbare Basis für Testmanager
*gute Tools sind mit den Anforderungen verknüpft
*Schwerpunkt ist due Verwaltung sämtlicher Testfälle sowie deren Fehlermeldungen.
*Status der Testfälle sichtbar

'''Testinformation-Repository'''
*ist Datawarehouse des ganzen Testprozesses.
*enthält strukturierte Daten (Datenbanken) wie auch unstrukturierte (Dateien)
*Suchfunktionen sind sehr wichtig

=== Tools für statische Prüfungen ===

'''Static Measurment Tools'''
*analysieren Code ohne diesen auszuführen.
*Prüfen von Programmier-Richtliniee
*verschtelungstiefe
*nicht erreichbaren Code
*Anzahl Zeilen
*Zugriff auf undefinierte Variablen

'''Complexity Analyzer'''
*untersuchen den Code auf Anzahl Parameter, Variablen, Bedingungen, Loops etc.
*dadurch kann Komplexität abgeschätz werden.

=== Tools für Testvorbereitung ===

*'''Codebasierte Testdatengeneratoren''' analysieren code und bilden eine Menge von Inputdaten (aber keine Sollwerte)
*'''Schnittstellenbasierte Testdatengeneratoren''' analysieren Interfaces und leiten mitteles Äquivalenzklassen- und grenzwertanalayse die testdaten davon ab.
*'''Massendaten-Generatoren''' bilden Testdaten welche vor allem für Perfomance-tests gebraucht werden.

=== Tools für Testdurchführung- und Auswertung ===
*'''Drivers''' simulieren aufrufende Programme (werden zum Testen von einzelnen Komponenten benötigt)
*'''Stubs''' simmulieren aufgerufene Funktionen ((werden zum Testen von einzelnen Komponenten benötigt)
*'''Capture- bzw. Playback-Tools''' sind testroboter. Sie zeichnen alles auf was der Tester macht. Der Test kann danach wieder abgespielt werden.
*'''Performance-Analyzer''' zeichnet das Systemverhalten während der Testphase auf.
*'''Coverage-Monitor''' prüft während der Ausführung den Abdeckungsgrad. In den Reports ist dann zu sehen welcher Codeteik noch nicht getestet wurde.
*'''Debugger'''
*'''Testresult-Comperator'''. Unabdingbar bei Massentest.

Alle diese Tools lassen sich nur sinnvoll nutzen wenn sie richtig in die Systemumgebung passen und von geschulten Leuten bedient werden.

= Berichtsdokumente =
Die '''Testdokumente''' bilden den gesamten dispositiven (planenden) Teil im Testprozess ab. Die '''Berichtsdoukmente''' beinhlaten sämtliche Informationen über die Testausführung und Auswertung

== Welche Aufgaben beiinhaltet die Testdurchführung ==
*Grundlegende '''Voraussetzungen''' für die Testaufsührung sind Kenntnisse über die zu testende Anwendung und die testwerkzeuge.
*Die Tester verfügen über das Testdrehbuch (führt Schritt für Schritt durch die Testarbeit)
*Tester dürfen aber trotzdem ihrer Intuition und ihrer Erfahrung folgen (explorative Tests)
*Aber alles muss '''sauber und vollständig protokolliert werden'''.
*Aufgrund der Informationen aus dem Testprotokoll kann der Testmanager die '''Testauswertungen vornehmen''' und den '''Status des Testfortschrittes''' bestimmen.

Produzierte Berichtsdokumente:

[[Image:BerichtsdokumenteTestausfue.gif]]

=== Tests durchführen ===
*Im Testdrehbuch ist ein Testszenario mit mehreren Testfällen beschrieben
*Die Abarbeitung entspricht einem Testlauf
*Ein Testprotokoll ist zu erstellen
*Eventuell ensteht je nach Test auch ein Testlog
*Wenn alle Kriterien erfüllt sind, gilt der Testlauf als "passed".
*Auch wenn nur ein Kriterium nicht erfüllt ist, gilt der Testlauf als "failed".
*Das Testprotokoll wird vom Tester in einer speziellen Software strukturiert erstellt.

=== Testprotokoll erstellen ===

*muss sich auf das Testdrehbuch beziehen
*muss folgende Infos enthalten: Datum/Uhrzeit des Tests, Name Tester, eingesetzte Testumgebung und Hinweis auf eventuelle Anomalien.
*eingesetzter Release und Build des Testlings
*enthält detailliertes Ergebnis aller Testfälle (passed, failed). Auch der persönliche EIndruck des Testers darf/kann erwähnt werden.

'''Problemmeldung für jede aufgetretene Abweichung'''

*jedes Problem eine Meldung
*Bei einem Problem kann es sich um Programmmierfehler, Nichterfüllung eines Akzeptanzkriteriums oder um etwas ganz andees handeln
*Zuerst ist das Fehlverhalten zu beschreiben (Resultat ist 50 statt 100)
*Danach die Fehlerwirkung (sichtbare Auswirkung)
*Hinweise auf die Reproduzierbarkeit
*Eventueller Workaround
*Eventuelle Vermutung des Testers was den fehler verusachen könnte.
*Für die Planung der Fehlerbehebung ist eine Einschätzung des Testers notwendig.

Folgende Klassifizierungen sind möglich:

[[Image:Klassifizierungproblem.gif]]

Problemstatus

[[Image:Problemstatus.gif]]

Problembearbeitungszyklus

[[Image:Problembearbeitungszyklus.gif]]

=== Fehler lokalisieren ===

*gehört nicht zum eigentlichen Testprozesss sondern zum Softwareentwicklungsprozess
*zu den bereits genannten Ursachen können zusätzliche auftauchen: Bedienungsfehler, nicht korrekte Testdaten, fehlerhaftes Testscript.

== Wie wird die testauswertung erstellt ==

*um dem PL und dem Auftraggeber über den projektstand informieren zu können, sind die Testauswertungen und ein sauberes Reporting ein absolutes MUSS.
*Aufpassen wegen dem 95%-Syndrom (jeder meint fast fertig zu sein, in Tat und Wahrheit sind es erst 70%)

=== Testmetriken ===
Die Testmetriken sind ein Versuch, Masseinheiten zu definieren um den Arbeitsfortschritt möglichst verständlich wiederzugeben.

'''Testabdeckung'''

kann auf verschiedene weisen gemessen werden.
*'''Coverage-Monitor''' (ermittelt den getesteten Code)
*'''Anwendungsfallabdeckung''': Wie viel Prozent der Use Cases sind schon getestet?
*'''Komponentenabdeckung''': Wie viel Prozent der Komponenten sind schon getestet?

'''Testeffizienz'''
*zeigt auf wie viele fehler in einer bestimmten Zeit gefunden wurden.
*Die Testeffizienz zeigt somit das verhältnis zwischen ingesetzten personellen ressourcen und gefunden Fehlern.

[[Image:Testeffizienz.gif]]

'''Fehlertrend'''

Die Fehlertrendstatistik sagt etwas über die Art der gefunden Fehler aus. Die Klassifizierung des Schweregrades liefert gegenüber dem testeffizienz-Diagramm eine detailliertere Sichtweise

[[Image:Fehlertrend.gif]]

'''Fehlerdichte'''
*ist das Verhältnis zwischen der Anzahl Fehler und der Grösse des Systems (meistens in Anzahl Codezeilen gemessen)

'''Testfortschritt'''
*Der Testfortschrittsbericht ist eine Zusammenfassugng und Beurteilung des Testmanagers des aktuellen Standes
*muss alle drei ewähnten Testmetriken beinhalten, und in einen Prozentwert versichten.
*Bedingt viel Erahrung

Beispiel:

[[Image:Testfortschritt.gif]]

=== Testberichtswesen ===
*Der testmanager fasst die Erkenntnisse und resultate in einem periodischen testbericht zusammen.
*wird dem PL abgegegen
*neben der allgeminen lager werden auch spezielle Vorkomnisse erwähnt.
*der Testbericht gibt die Ist-Werte, die Soll-Werte und die Abweichungen an-
*Aufgrund der Abweichungen sind Massnahmen vorzuschlagen
*Bei einem speziellen Vorkommnis muss der Testmanager sofort einen Testvorfallsbereicht zu Handes des PL verfassen (z.B. krankitsbedingertr Aufall, verspätete Lieferung.
*Alles was den geplanten Ablabuf und die termine gefährdet muss so schnell wie möglicg gemeldet werden.

=== Massnahman ableiten ===
*Der Testmanager ist verantwortlich dafür notwendige bzw. mögliche Massnahmen aufzuzeigen
*Seine Kompetenzen sind meist sehr beschränkt.
*Deshlab muss er Antrag an PL sctellen.
*Aufgrund der Schlüsselfaktoren (Testabdeckungsgrad, fehlertendenz, Fehlerdichte etc.) sind folgende Massnahmen zu beantragen:
**Testunterbruch
**Anpassen der Ressourcen
**Terminverschiebung
**Testende

=== Testabschlussbericht ===
*ist eine zusammenfassende Darstellung des kompletten testprojkets.
*darin werden die Testaktivitäten beschrieben (oder aufgelistet), die Testergebnisse zusammengefasst und und eine Tachkalkulation des Testaufwandes vorgenommen.
*ist der formelle Abschluss der Testarbeiten

= Ergänzungen Migros Klubschule =

'''Fehlerbegriffe'''
*'''Fehler''' ist die Nichterfüllung einer festgelegten Anforderung
*Ein '''Mangel''' liegt vor, wenn eine gestellte Anforderung oder eine berechtigte Erwartung nicht angemessen erfüllt wird.
*Eine '''Fehlerwirkung'''(failure) oder ein Äusserer Fehler bezeichnet das Sichtbarwerden eines Fehlers für den Anwender oder Tester.
*Ein '''Fehlerzustand'''(fault)–auch Defekt oder innerer Fehler–ist die Ursache für das Auftreten einer Fehlerwirkung.
*Eine '''Fehlermaskierung''' bedeutet, dass zwei oder mehr Fehlerzustände sich gegenseitig nach aussen hin kompensieren, so dass eine Fehlerwirkung nicht auftritt, bis einer der maskierenden Fehler korrigiert ist.
*Eine '''Fehlhandlung'''(error) ist die Ursache für einen Fehlerzustand oder Defekt und stellt eine Fehlhandlung einer Person dar, etwa die fehlerhafte Programmierung eines Entwicklers.

'''Kriterien für die Priorisierung'''
*Eintrittswahrscheinlichkeit einer Fehlerwirkung
*Fehlerschwere
*Wahrnehmung einer Fehlerwirkung
*Priorität der Anforderungen
*Komplexität der Komponenten

'''Prinzipien des Softwaretestens'''
*Grundsatz 1: Testen zeigt die Anwesenheit von Fehlern
*Grundsatz 2: Vollständiges Testen ist nicht möglich
*Grundsatz 3: Mit dem Testen frühzeitig beginnen
*Grundsatz 4: Häufung von Fehlern
*Grundsatz 5: Wiederholungen haben keine Wirksamkeit
*Grundsatz 6: Testen ist abhängig vom Umfeld
*Grundsatz 7: Trugschluss: Keine Fehler bedeutet ein brauchbares System

'''Die Stufen im allgemeinen V-Modell'''
*'''Programmierung''': Programmierung jedes spezifizierten Bausteins in einer Programmiersprache.
*'''Komponententest''': Prüfung, ob jede Komponente für sich den Vorgaben seiner Spezifikation entspricht.
*'''Integrationstest''': Prüfung, ob Gruppen von Komponenten, wie sie im technischen Systementwurf vorgesehen sind, zusammenspielen sowiedie Prüfung der Interaktionen zwischen verschiedenen Teilen eines Systems
*'''Systemtest''': Prüfung ob das implementierte System den spezifizierten Anforderungen entspricht.
*'''Abnahmetest''': Prüfung, ob das System aus Kundensicht die vertraglich vereinbarten Leistungsmerkmale aufweist.

Informatiker FA M175 Zusammenfassung

2019-08-01T13:19:42Z

Christian: Created page with "= Probleme der SW-Entwicklung = *Es werden immer grössere und schwierigere Aufgabe durch SW unterstützt. *Dadurch wird SW immer komplexer *SW ist nach wie vor Handwerkskuns..."

= Probleme der SW-Entwicklung =

*Es werden immer grössere und schwierigere Aufgabe durch SW unterstützt.
*Dadurch wird SW immer komplexer
*SW ist nach wie vor Handwerkskunst (trotz CASE Tools)
*Benutzeranforderungen lassen sich nicht immer 1:1 umsetzen
*Anforderungen ändern sich immer wieder.
*SW kann man nicht anfassen, daher ist der Zustand schwer einzuschätzen.
*Auch die SW-Qualität ist schwer zu fassen. Der Zusammenhang zwischen messbarem und das was SW-Qualität wirklich ausmacht ist nicht immer klar.
*Die Qualitätsanforderungen nehmen zu. SW-Fehler können Menschenleben gefährden.

Softwareentwicklung bewegt sich im Dreieck Zeit - Qualität - Kosten.

== Bedeutung methodisches Vorgehen ==

*Wichtigste Erkenntnis der letzten 50 Jahre: konsequente Anwendung von '''Methodik'''.

Um für den Einsatz von Methodik das richtige Mass zu finden, ist es nützlich, sich die Zielsetzung zu vergegenwärtigen. Ziel des methodischen Vorgehens sind:

*Durch eine sachlogische begründbare, auf bewährten Prinzipien basierende Vorgehensweise klar definierte Ziele zu erreichen.
*Die Entwicklungsrisiken mindern
*Mehr Sicherheit bei der Schätzung des Aufwandes (dadurch Zeitplan und Kosten einhalten)
*Die Anforderungen in der vordefinierten Qualität umsetzen.
*Den Entwicklungsprozess wiederholbar und unabhängig von bestimmten Personen zu machen.

Der konsequente Einsatz von Methoden verursacht keine zusätzlichen Kosten, sondern vermindert diese. Vor allem Test- und Fehlerkosten.

Die Erfahrung zeigt: Je ausgeprägter der Methoden-Einsatz desto geringer die Entwicklungskosten und desto höher die Produktqualität.

= Entwicklungsprozesse =

Eine zentrale Komponente jeder Methode besteht in der Beschreibung der Vorgehensweise. So wie ein gutes Rezept zu einem guten Kuchen beiträgt, führt eine bewährte Vorgehensweise bei der Entwicklung mit hoher Wahrscheinlichkeit zu einem qualitativ hoch stehenden SW-Produkt.

== Vorgehensmodelle ==

Die professionelle Erstellung von SW erfordert folgende Haupttätigkeiten:
*Fachliche und technische Entwicklung sowie Wartung und Pflege
*Management = fachliche Führung und wirtschaftliche Kontrolle
*QS

Ein bedeutender Schritt von der SW-Bastelei zur professionellen Softwareproduktion ist die Verwendung von '''Vorgehensmodellen'''. Durch Vorgehensmodelle wird der SW-Entwicklungsprozess in aufeinander abstimmte '''Phasen''' zerlegt. Für jede Phase werden '''Tätigkeiten und Ergebnisse''' festgelegt. Bekannte Vorgehensmodelle sind:

*das Wasserfallmodell
*das Spiralmodell
*das prototyping-orientierte Live-Cycle-.Modell
*das V-Modell
*der Rational Unified Process (RUP)

== Entwicklungsphasen ==

Als Kern der meisten Modell haben sich folgende Phase herauskristallisiert

[[Image:Entwicklungsphase.gif]]

=== Planungsphase (Vorstudie) ===

*Vor dem eigentlich Entwicklungsstarts des Produktes
*Es wird durch eine Vorstudio die fachliche, ökonomische und personelle Durchführbarkeit gezeigt.
*Am Ende wird entschieden: weitermachen oder beenden, wenn weitermachen, mit welcher Lösungsvariante etc.

Die Planungsphase beinhaltet u.a. folgende Aktivitäten
*'''Situationsanalyse und Zielformulierung'''. Was ist das zu lösende Problem, welche Anforderungen, was soll erreicht werden, was gehört dazu, was gehört nicht dazu, soll entwickelt oder gekauft werden.
*'''Voruntersuchung des Produktes'''. Ist-Aufnahme wenn eine Vorgänger vorhanden ist, Hauptanforderungen festlegen, Leistungsmerkmale festlegen, Hauptaspekte der Benutzeroberfläche festlegen, wichtiges Qualitätsmerkmale
*'''Untersuchung der Durchführbarkeit'''. fachlich, personell, alternative Lösungsvorschläger, Risiken.
*'''Prüfung der ökonomischen Durchführbarkeit'''

Die Ergebnisse dieses Tätigkeit münden in einer Studie die folgende Teildokumente enthalten kann:

*Grobe Anforderungsspezifikation
*Projektkalkulation
*Projektplan

Eine grobe Anforderungsspezifikation kann z.B. folgenden Aufbau haben:
*Zielbestimmung
*Produkteeinsatz
*Hauptfunktion und Hauptdaten
*Leistungsmerkmale
*Anforderung an die Benutzeroberfläche
*Qualitätsanforderungen

Die Tätigkeiten der Vorstudie haben das ziel zu prüfen ob eine Produkt entwickelt werden soll. Wenn die Entscheidung zum Kauf einer fertige Anwendung getroffen wird, diese dir grobe Anforderungsspezifikation als Vorgabe für die Evaluation. Wenn entwickelt werden soll, wird die grobe Anforderungsspezifikation im Rahmen der Definitionsphase erweitert und verfeinert.

=== Definitionsphase (Analyse) ===

Eine wichtige Tätigkeit stellt das Definieren der Anforderungen dar. Anforderungen legen die qualitativen und quantitativen Eigenschaften eines Produktes aus der Sicht des Auftraggebers fest. Die systematische Vorgehensweise um die Anforderungen in einem iterativen Prozess zu ermitteln bezeichnet man als Systemanalyse (requirements engineering)

Anforderungen sind zuerst oft vage, verschwommen, unzusammenhängend und widersprüchlich. Aufgabe des Definitionsprozesses ist es, aus diesen Anforderungen ein vollständiges, konsistentes und eindeutiges Anforderungsdokument zu erstellen.

Die fertig gesellte Produkt-Definition besteht aus folgenden Teildokumenten:
*Anforderungsspezifikation (detailliert)
*Produktemodell
*Konzept der Benutzerinteraktion

=== Entwurfsphase (Design) ===

Aufgabe des Entwerfens ist es, aus den gegebenen Anforderungen an ein Softwareprodukt eine software--technische Lösung im Sinne einer konkreten Afo6tware-Architektur zu entwickeln. Entwerfen wird auch als "Programmieren im grossen" bezeichnet. Die Ergebnisse der Analysephase bilden den Ausgangsprunk für das Entwerfen. Das Entwurfsergebnis wiederum ist die Voraussetzung für die Realisierung.

Ziel des Software-Entwurfs ist es, für das zu entwerfende Produkt eine Software-Architektur zu erstellen, welche die funktionalen Produkteanforderungen sowie allgemeine und produktespezifische Qualitätsanforderungen erfüllt und die Schnittstellen zur Umgebung versorgt.

Eine Software-Architektur beschreibt die Struktur des zu erstellen Systems durch Komponenten und ihrer Beziehungen untereinander. Zu den wichtigsten Ergebnissen des Entwurfs zählen somit die Module. Je nach eingesetzter Methode können das sein:

*Funktionale Module
*Datenobjekt-Module
*Datentyp-Module

=== Realisierungsphase (Implementation) ===

Die Programmiertätigkeiten werden in der Realisierungsphase (auch: Implementationsphase) durchgeführt. Sie ist zwischen Entwurfsphase und Einführungsphase eingebettet.

Die Realisierungsphase beinhaltet u.A. folgende Tätigkeiten:

*Datenstrukturen und Algorithmen konzipieren
*Programme strukturieren
*Implementationsentscheidungen dokumentieren
*Konstrukte der verwendeten Programmiersprache umsetzen
*Entwickelte Programm testen und verifizieren.

Ergebnisse:
*Quellprogramme inkl. Doku
*Lauffähige Objektprogramme
*Detaillierte Testplanung und Testprotokolle

=== Einführungsphase ===

In dieser Phase wird das fertig gestellte Produkt inkl. Doku abgenommen und bei Anwender eingeführt (in Betrieb genommen). Ab diesem Zeitpunkt unterliegt das System der Wartung.Die Einführungsphase beginnt mit der Übergabe an den Auftraggeber. Dieser ist verantwortlich für die Abnahmetests und protokolliert diese.

Folgende Tätigkeiten werden weiter ausgeführt:
*Installation des Produktes (für den betrieb)
*Schulung der Benutzer und Betriebspersonal
*Inbetriebnahme des Produktes mit produktiven Daten.

Die Installation in der Zielumgebung kann mit umfangreichen Aktivitäten verbunden sein.
*Integration in bestehende Umgebung
*Pilotierung
*Rahmenorganisation

= Systemanalyse =
Die Anforderungsdefinition (=Spezifikation) ist die Kommunikationsbasis um eine Vereinbarung über die geplante SW zu erreichen. Dabei ist es wichtig, dass Entwurfs- und Realisierungsentscheidungen während der Definitionsphase so weit als möglich vermieden werden.

== Anforderungsdefinition ==

=== Anforderungsanalyse ===
Anforderungen legen die qualitativen und quantitativen Eigenschaften des Produktes aus Sicht des Arbeitgebers fest. Die systematische Vorgehensweise um die Anforderungen in einem iterativen Prozess zu ermitteln, bezeichnet man als '''Systemanalyse'''. Diese beinhaltet folgende Aktivitäten:

*Anforderungen ermitteln
*Anforderungen festlegen und beschreiben
*Anforderungen analysieren
*Anforderungen simulieren und ausführen (exploratives Prototyping)
*Anforderungen verabschieden.

Anforderungen sind am Anfang noch vage, verschwommen, unzusammenhängend, unvollständig und widersprüchlich. Aufgabe des Definitionsprozesses ist es aus diesen Anforderungen ein vollständiges, konsistentes und eineindeutiges Anforderungsdokument (Produkt-Definition) zu erstellen.
Die Produkt-Definition ist unter andrem deshalb so wichtig weil sie die Basis für die Abnahme des fertigen Produktes ist.

=== Was sind Anforderungen ===

Anforderungen können in funktionale und nicht-funktionale Anforderungen unterschieden werden.

*Funktionale Anforderungen definieren die Funktionen die eins System ausführen können muss (Transformation beschreiben welches aus einem Input einen Output macht)
*Nicht-funktionale Anforderungen sind Restriktionen und Qualitätsanforderungen wie z.B. Performance, Zuverlässigkeit, Wartbarkeit, Gestaltung der Benutzungsschnittstelle, Sicherheitsanforderungen, Portabilität, Erfüllung von Standard etc.

Hinweis: Aus nicht-funktionalen Anforderungen können funktionale werden; z.B. die Erfüllung von Sicherheitsstandars kann nur von entsprechenden Zusatzfunktionen erreicht werden.

=== Zur Bedeutung der Systemanalyse ===
*bildet in vielerlei Hinsicht das '''Fundament''' für ein Softwaresystem
*zwingt den Benutzer seine Anforderungen sorgfältig zu bedenken und in Zusammenhang mit seinen Problemen und Zielen zu betrachten.
*Im Verlaufe der Erarbeitung der Anforderungsdefinition findet eine intensive Auseinandersetzung zwischen Benutzer und Entwickler statt.
*Die Systemanalyse fördert zugleich die Entwicklung von '''Plänen für den Abnahmetest'''.
*gegen die Anforderungsspezifikation wird das implementierte Produkt auf Korrektheit und Vollständigkeit getestet.
*unterstützt das Projektmanagement indem daraus Schätzungen bezüglich Zeit, Kosten und anderer Ressourcen abgeleitet werden können.
*es können auch schon Rahmenbedingungen für zukünftige Änderungen und Wartungsarbeiten festgelegt werden.

Wesentlich für eine Anforderungsdefinition ist es den Auftraggeber angemessen einzubinden. Die Systemanalyse bildet von Anfang an die Basis für eine vertrauensvolle Zusammenarbeit zwischen Benutzer und Entwickler welche erfahrungsgemäss nach der erfolgten Realisierung des Produktes nicht abgeschlossen ist.

=== Exploratives Prototyping ===

Ein verbreitetes Problem bei der Erarbeitung der Anforderungsdefinition ist, dass Benutzervertreter bzw. Analytiker sich nicht vorstellen können, wie die geplante Applikation funktionieren soll. Die verbale bzw. grafische Beschreibung reicht oft nicht aus, um eine ausreichend klare Vorstellung vom zu entwickelnden Produkt zu erhalten.

Der explorative Prototyp dient der Veranschaulichung und Klärung der Anforderungen. Das Ziel beim exploratoiven Prototyping ist also eine möglichst vollständige Systemspezifikation. Es geht den Entwicklern nur darum, verschiedene Lösungsansätze mit dem Anwender zu klären.

== Ausgestaltung der Anforderungsdefinition ==

=== Anforderungsdefinition nach IEEE ===

Als Muster für verbale Anforderungsbeschreibungen mit festgelegtem Gliederungsschema kann ANSI/IEEE Std-830-1984 angesehen werden

[[Image:IEEEStd-830-198.gif]]

=== Qualitätsziele der Anforderungsdefinition ===

Beschriebene Anforderungen sind auf folgende Qualitätsziele zu analysieren:

*Sind die Anforderungen inhaltlich vollständig?
*Sind die Anforderungen konsistent? (untereinander widerspruchsfrei)
*Sind die Anforderungen eindeutig? (eindeutige, nicht unterschiedliche interpretierbaren Anforderungen)
*Sind die Anforderungen durchführbar? (z.B. technisch mit der geplanten Plattform möglich)
*Sind die Anforderungen als Vorgabe für den Abnahmetest geeignet?

= Strukturierte Analyse =

Dir Strukturierte Analyse (SA) dient dazu, die Definition von Anforderungen an komplexe System zu vereinfachen. Dazu legt die SA fest, welche Ergebnisse zu erbringend sind um die nachfolgende Phase Strukturiertes Design (SD) in Angriff zu nehmen. Dazu werden Techniken zur Verfügung gestellt die aufeinander abgestimmt sind.

Die Modellierung nach SA hat zum Ziel das so genannte essenzielle Modell des System zu erstellen. Darin wird beschrieben was ein System tun muss und welche Informationen vorhanden sein müssen. Die beschreibung in dieser Form ist auch für den Benutzer verständlich.

== Methode der strukturierte Analyse ==

*In der SA enthält das Modell keine Implementationsdetails
*es werden die wahren Anforderungen des Anwenders wiedergegeben. d.H. diejenigen Funktionen die unabhängig von der Implementation verfügbar sein müssen.

=== Umgebungs- und Verhaltensmodell ===

Das essenzielle Modell besteht aus zwei Komponenten:

*Dem Umgebungsmodell bestehend aus Ereignistabelle, Kontextdiagramm und einer Kurzbeschreibung der Aufgabe des Systems
*Dem Verhaltensmodell bestehend aus Datenflussdiagramm, Prozessbeschreibung, Datenkatalogeinträgen, ERD.

Das Umgebungsmodell beschreibt das System als '''Blackbox''', das Verhaltensmodell als '''White-Box'''

[[Image:UmgebungsVerhaltensmodell.gif]]

=== Das Hierarchiekonzept der strukturierten Analyse ===

*Problem: Bei umfangreichen Aufgabenstellungen kann ein Datenflussdiagramm (DFD) mehrere Seiten umfassen.
*Die Lösungsidee der SA besteht darin, das DFD hierarchisch zu verfeinern.
*Nachdem auf Basis der Ereignistabelle das Kontextdiagramm erstellt worden ist, wird dieses in Form des '''Datenflussdiagramm Level 1''' verfeinert.
*Zu diesem Zweck werden Prozesse identifiziert welche die Datenflüsse verarbeiten/generieren.
*Für jeden Prozess der in '''Teilprozesse''' aufgeteilt werden kann, wird ein weiteres DFD auf der nächsten Detaillierungsstufe gezeichnet.
*Auf diesen Weise werden DFD stufenweise verfeinert (Level 1, Level 2 ...)
*Dies wird so lange fortgesetzt bis die Teilprozesse nicht mehr sinnvoll zerlegt werden können (bis '''Elementarprozesse''' entstanden sind)
*Jeder Elementarprozess wird schliesslich durch eine Mini-Spezifikation beschrieben.

[[Image:HirarchiekonzeptSA.gif]]

== Techniken der strukturierten Analyse ==

=== Ereignistabelle ===

Die Ereignistabelle zeigt durch welche Ereignisse das System aktiviert wird. Zu jedem Ereignis gehört ein konkreter Auslöser in Form eines externen Datenflusses und eine Reaktion im System.

Beispiel Seminar-Hotel:

{| border="1"
! Nr !! Ereignis !! Auslöser !! Antwort/Reaktion
|-
| 1 || Gast wünscht Zimmerreservation || Reservation || Reservationsbestätigung
|-
| 2 || Auftraggeber fragt Dienstleistung an || Anfrage || Offerte
|}

*Eine Ereignistabelle beschreibt diejenigen Ereignisse die im System ein Aktion auslösen und eine oder mehrere Antworten bzw. Reaktionen.
*Man unterscheidet zwischen externen und zeitlichen Ereignissen
*Es werden nur Ereignisse in die Liste aufgenommen welche ein nach aussen sichtbare Reaktion des Systems auslösen.
*Bei der vereinfachten Form der Ereignistabelle wird die Spalte "Auslöser" weggelassen. Der Auslöser wird dann in der Ereignisbeschreibung erwähnt.

Im nächsten Schritt werden die Auslöser und Reaktionen im Kontextdiagramm grafisch dargestellt

=== Kontextdiagramm ===

Das Kontextdiagramm ist ein Datenflussdiagramm das die Schnittstellen des zu modellierenden Systems mit seiner Umwelt beschreibt.

Im Compendio-Buch werden folgende drei Symbole folgende Notation verwendet:

*Applikation, dargestellt durch ein Rechteck; damit wird das System als ganzes symbolisiert.
*Schnittstelle zur Umwelt, dargestellt durch ein Rechteck mit Schatten, das den Schnittstellennamen enthält.
*Datenfluss, dargestellt durch einen beschrifteten Pfeil. Manchmal werden zum einfacheren Verständnis auch Informationsflüsse (gestrichelt) zwischen den externen Partnern gezeichnet.

'''Syntaktische Regeln'''
*Das Kontextdiagramm enthält nur einen Prozess, nämlich die Applikation als Ganzes.
*enthält mindestens eine Schnittstelle.
*zwischen den Schnittstellen gibt es keine Datenflüsse
*enthält keine Speicher und keine Funktionen

Semantische Regeln:
*beschriebt den Anwendungsbereich des zu modellierenden Systems (problem domain, Untersuchungsbereich)
*es zeigt die Datenflüsse welche die Systemgrenzen passieren.
*Eine Schnittstelle ist so zu wählen, dass sie die ursprüngliche Quelle oder Senke (Ziel)einer Information angibt.

Mögliches Kontextdiagramm für Seminar-Hotel:

[[Image:KontextdiragrammHotel.gif]]]

Die Beschreibung darf nicht zu abstrakt aber auch nicht zu detailliert sein. Wichtig ist, dass jemand der sich in ein System neu einarbeiten muss, anhand des Kontextdiagramm die wesentlichen Informationen über die Umwelt des Systems (inkl. Datenströme) erhält.

Das Kontextdiagramm wird durch eine Kurzbeschreibung in Textform ergänzt.

Beispiel: ''Die Applikation "Seminar-Hotel" erlaubt es ......."''

Der Prozess im Kontextdiagramm beschreibt das gesamte zu modellierende System. Dieser Prozess wird anschliessend in Teilprozesse gegliedert und ein einem DFD dargestellt.

=== Datenflussdiagramm (DFD) ===
Ein Datenflussdiagramm (data flow diagramm) beschreibt die Wegen von Daten bzw. Informationen zwischen Funktionen, Speichern und Schnittstellen sowie die Transformation der Daten bzw. Informationen durch Funktionen

In der deutschsprachigen Schweiz ist die folgende Notation mit vier Symbolen weit verbreitet:

*Funktion bzw. Prozesse, dargestellt durch ein Rechteck mit dem Namen der Funktion
*Datenfluss, dargestellt durch einen beschrifteten Pfeil
*Schnittstelle zur Umwelt, dargestellt durch ein Rechteck mit Schatten, das den Schnittstellennamen enthält.
*Datenspeicher, dargestellt durch ein abgerundetes Rechteck, in dem der Speichername steht.

Das DFD stellt dar welche Informationen von wo nach wo durch das System fliessen. Es wird nicht dargestellt, wie es initiiert wird, oder in welcher Reihenfolge dies ausgeführt wird.

*jedes zu entwickelnde System hat Schnittstellen zur Umwelt.
*Die Umwelt liefert Informationen die vom System verarbeitet werden.
*Die Umwelt nimmt Informationen auf welche vom System erzeugt wurden.
*Nur das System wird modelliert. Die Umwelt nicht.
*Informationen kommen aus Informationsquellen und fliessen zu Funktionen.
*Eine Funktion transformiert ankommende Datenflüsse in ausgehende Datenflüsse.
*Speicher sind Hilfsmittel zur Ablage von Informationen.
*Informationen können in einen Speicher geschrieben und daraus wieder gelesen werden.

Beispiel DFD "Seminar-Hotel"

[[Image:DFD SeminarHotel.gif]]

'''Syntaktische Regeln'''
*Ein DFD enthält mindestens eine Schnittstelle
*Zwischen Schnittstellen gibt es keine Datenflüsse. Zur Erläuterung können Informationsflüsse gestrichelt eingetragen werden. Sie sind aber für die Spezifikation des Systems nicht wichtig.
*Jeder Datenfluss hat einen Namen. Ausnahme: Datenflüsse die zu einem Speicher führen oder dort beginnen und keinen Namen haben, transportieren die gesamten gespeicherten Daten.
*Zwischen Speichern gibt es keine direkten Datenflüsse
*Zwischen Schnittstellen und Speichern dürfen keine direkten Datenflüsse gezeichnet werden.

'''Semantische Regeln'''
*Das DFD beschriebt den Datenfluss, nicht den Kontrollfluss.
*Es enthält weder Entscheidungen noch Schleifen
*Es wird keine Aussage über die Initiierung, Terminierung oder Abfolge von Funktionen gemacht.
*Ein Schnittstelle ist so zu wählen, dass sie die ursprüngliche Quelle oder Senke(Ziel) angibt (jedoch wenn möglich nicht "Tastatur" oder "Drucker").
*Ein Datenflussname besteht aus einem Substantiv (Nomen) oder einem Adjektiv (Eigenschaftswort) und einem Substantiv.
*Als Datenflussnamen sollten keine seichten Namen wie "Daten" oder "Informationen" verwendet werden. Stattdessen soll der Namen auch etwas über die fliessenden Daten aussagen (z.B. Gästedaten, Buchungsdaten etc.)
*Funktionsnamen repräsentieren Aktionen; ein Funktionsname besteht au seinem einzigen starken Aktions-Verb gefolgt von einem einzigen konkreten Objekt (z.B. erstelle Adresskleber) oder einem konkreten Substantiv gefolgt von einem starken Aktions-Verb (z.B. Adressaufkleber erstellen". Seichte Namen wie "verarbeite", "bediene" sind zu vermeiden.

'''Inhaltliche Regeln'''
*Wird in einen Datenspeicher geschrieben, so muss auch wieder gelesen werden (und umgekehrt)
*Alle Daten die aus einer Funktion herauskommen, müssen auch in diese eingeflossen sein.
*Jede Funktion hat mindestens einen Eingangs- und Ausgangsdatenfluss.
*DFD sollten nur die wesentliche Verarbeitung beschreiben. Einzelheiten wie Prüfroutinen, Fehlerbehandlung, Datenadministration, Initialisierung, Drucken gehören nichts ins DFD

Die inhaltliche Qualität kann mit einer '''Handsimulation''' geprüft werden.

'''Bewertungen:'''

*DFD sind leicht zu erstellen und sind gut lesbar
*werden auch von Auftraggebern verstanden (gut vermittelbar)
*ein DFD enthält mehr Informationen als eine Funktionsbaum
*Wenn ein ganzes System dargestellt werden soll, wird das Diagramm schnell zu gross und unübersichtlich.
*es ist schwierig bei den Daten und Funktionen ein einigermassen einheitliches Abstraktionsniveau einzuhalten.
*Die Bezeichnung der Datenflüsse reicht nicht aus. Man muss den Datenaufbau kennen um eine Handsimulation durchführen zu können.

[[Image:DFD SeminarHotel Level2.gif]]

Wichtige Regeln bei der Erstellung eines SA-Modells:
*Schnittstellen können nicht verfeinert werden. Jedoch können die im Kontext-Diagramm aufgeführten Schnittstellen unverändert in verfeinerten Diagrammen dargestellt werden, wenn dies die Verständlichkeit fördert.
*Speicher können nicht verfeinert werden. Jedoch können Speicher, nachdem sie in einem Diagramm eingeführt wurden, auf allen Verfeinerungen dieses Diagramms unverändert wiederholt werden.
*Die Anzahl der Prozesse auf einem Diagramm sollte nicht wesentlich grösser als sieben sein (7 +/- 2-Regel). Sonst zusätzliches Diagramm.

'''Hinweise:'''
*wenn die Anzahl und Struktur der Speicher schwierig zu ermitteln ist, empfiehlt es sich die SA-Modellierung zu unterbrechen und zunächst ein ER-Modell (Entity-Relationship-Modell) zu erstellen. Aus dem ER-Modell ergibt sich dann die Anzahl der benötigten Speicher.
*Die Erstellung eines SA-Modells ist ein iterativer Prozess. Es werden mehrere Durchgänge benötigt bis sich ein stabiles SA-Modell ergibt.

=== Data Dictionary (DD) ===

*Ein DD ist ein Verzeichnis, das Informationen über die Struktur von Daten, ihre Eigenschaften sowieso ihrer Verwendung enthält.
*Die Informationen des DD werden z.B. zur Konsistenzüberwachung eines Datenbestandes benötigt.
*entsteht in der Definitionsphase und wird in der Entwurfs- und Realisierungsphase weiter verwendet und ergänzt.
*Das Hauptziel des DD ist es, die in den DFD verwendeten Bezeichnungen der Datenflüsse und Datenspeicher zu definieren.
*In der einfachsten Form des DD wird für die Bezeichnungen definiert aus welchen Elementen sie bestehen.

Hier ein mögliches DD für das "Seminar-Hotel"

{| border="1"
! Bezeichnung !! Elemente
|-
| Kunde || = Personal-Nr. + Name + Adresse + Geburtsdatum + Funktion + Umsatz
|-
| Name || = Anrede + Titel + Vorname + Nachname
|-
| Adresse|| = Strasse + Haus-Nr. + Postfachnummer + Länderkennzeichen + PLZ + Ort + Telefon + Fax
|}

Ausgehen von abstrakten Daten, z.B. Kundendaten, werden dieser schrittweise verfeinert (Kundendaten, Adresse, Ort). Die Verfeinerung wird beendet wenn die Daten nicht weiter zerlegt werden können.

Unter Umständen ist es sinnvoll die Datenbeschreibung zusätzlich zu strukturieren. z.,B. Backup-Naur-Form (BNF):

[[Image:BNF1.gif]]

Beispiel:

[[Image:BNF Beispiel.gif]]

=== DD-Einträge und Datenintegrität ===
DFD werden Schritt für Schritt verfeinert. Auch die Datenflüsse werden verfeinert. Woher weiss man nun aber, welche Datenflüsse zwischen zwei Diagrammen wie zusammengehören. Diese Problem löst man in der SA mit folgenden Forderungen:

*Jeder Datenfluss trägt einen Datenflussnamen (Ausnahme: Datenfluss zu einem Speicher wenn auf den gesamten Inhalt zugegriffen wird)
*Jeder Datenflussname ist im DD definiert
*jeder Speicher trägt einen Namen
*jeder Speichername ist im DD definiert.

Die Zusammenhänge zwischen zwei Diagrammen werden also über die DD-Einträge hergestellt. Alle Datenflüsse eines untergeordneten DFD müssen im übergeordneten entweder unter gleichem Namen erscheinen oder Teilkomponente eines Datenflusses sein. Ist diese Eigenschaft in allen Diagrammen erfüllt, dann spricht man von einem '''ausbalancierten Datenflussmodell''' (Überprüfung durch CASE-Tool).

=== Mini-Spezifikation (MiniSpec) ===
*ist eine inhaltliche Beschreibung eines Prozesses.
*jeder Prozess eines DFD, der nicht durch ein weiteres DFD verfeinert wird, muss durch eine MiniSpec beschrieben werden.
*jede MiniSpec beschreibt wie Eingaben (Datenflüsse) in den Prozess fliessen und in Ausgaben transformiert werden.
*durch die Verknüpfung der Eingaben mit den Ausgaben kann festgestellt werden, ob die Erzeugung aller Ausgaben mit Hilfe der vorhandenen Eingaben möglich ist.
*MiniSpec darf keine Implementationsvorschriften enthalten
*MiniSpec ergänzt DFD, aber ersetzt sie nicht.
*werden durch normalen Text, Pseudocode oder Entscheidungstabellen beschrieben.

=== Funktionsbaum ===

*Eine funktionale Hierarchie entsteht, wenn eine allgemeine Funktion in Teilfunktionen gegliedert wird.
*wirf oft in Form eines Funktionsbaumes dargestellt.
*Funktionen werden als beschriftete Rechtecke ("Kästchen") gezeichnet und mit unbeschrifteten Linien verbunden.

Beispiele:
[[Image:Funktionsbaum1.gif]]

[[Image:Funktionsbaum2.gif]]

*Eine Funktion solle entweder durch ein Verb und ein Objekt (verwalte Kunden) oder ein Substantiv und ein Verb (Kunden verwalten) bezeichnet werden.
*Bezeichnung muss durchgängig sein.

Folgende Regeln sind bei der Erstellung zu beachten:
*Unter einer gemeinsamen Vaterfunktion sollen nur Funktionen angeordnet werden, welche zusammengehörende Tätigkeiten beschreiben (kann nur mit Fachwissen entschieden werden).
*Auf einer Hierarchieebene sollen Funktionen angeordnet sein, dir sich auf dem selben Abstraktionsniveau befinden.

Fazit:
*bewährtes Konzept zur systematischen Gliederung von Funktionen
*Gibt erste Hinweise für mögliche Dialoggestaltung
*sehr einfach einsetzbar, berücksichtigt aber nur die funktionale Sicht.

Im Allgemeinen enthält ein DFD nur solche Funktionen die in einem Funktionsbaum vorkommen, dort derselben Hierarchieebene angehören und dieselbe Vaterfunktion besitzen.

=== Bewertung der SA ===

Vorteile der SA:
*Geschickte Kombination bewährter Basistechniken
*Verbesserung der Übersichtlichkeit durch hierarchisch gegliederte DFD
*viele analytische Qualitätssicherungsmöglichkeiten durch Quervergleiche.
*Leicht erlernbar
*Auch für den Auftraggeber nachvollziehbar
*Erlaubt eine top-down Einarbeitung in ein System
*Durch CASE-Tools gut unterstützt.
*Zusammenhang zu ER-Modell über Speicher gut herstellbar.
*Durch die DFD-Hierarchie entsteht implizit auch ein Funktionsbaum.

Nachteile:
*Schnittstellen können nicht verfeinert werden. Dadurch: Darstellungsprobleme bei umfangreichen Schnittstellen.
*Speicher können nicht verfeinert werden.

== Qualitätssicherung ==

*grosse Stärke des SA:Modell: vielfältige QS-Analysen möglich
*jede Basistechnik kann überprüft werden.
*Quervergleiche zwischen DFD und DD sowie DFD und Minispec sowie Minispec und DD möglich.

Die syntaktische Überprüfungen können CASE_Tool übernehmen, die semantischen müssen per Review erfolgen.

=== Allgemeine Anforderungen an das Modell ===

*Das Modell soll nur so komplex sein, dass ein durchschnittlicher Leser nicht überfordert wird.
*Ein DFD sollte nicht mehr als 7 (plus/minus zwei) Prozesse enthalten
*Eine Zerlegung muss alle für das Verständnis notwendige Informationen enthalten.
*hat man mehrere Möglichkeiten, eine Aktivität auszudrücken, wählt man die mit den wenigsten Aktivitäten und Datenspeichern
*alle Eigenschaften weglassen welche sowieso selbstverständlich sind.
*Die Definition des Systems soll keine Hinweise auf die Technolgie beinhalten.

=== DFD-Semantik ===

Die Semantik der DFD einschliesslich der DFD-Hierarchie kann durch folgend Fragen überprüft werden:

*benötigt ein Prozesse zusätzliche Eingabedaten welche nicht verfügbar sind?
*prüfe ob alle Ausgabendatenflüsse mit den vorhanden Eingabedatenflüsse erzeugt werden können?
*besitzt ein Prozess überflüssige Eingabedaten?
*Prozessname irreführend?
*Prozessname allgemein.

=== DFD-Syntax ===

*Gibt es Speicher welche nur beschrieben oder nur gelesen werden?
*überdurchschnittlich viele Eingabe- und/oder Ausgabedatenflüsse?
*namenloser Datenfluss? (nur bei Speichern zulässig)

=== Konsistenz ===

Zwischen DFD und DD sowieso zwischen MiniSpec, DFD und DD gibt es viele Möglichkeiten die Konsistenz zu prüfen:

*Ein- und Ausgaben
*überflüssige Definitionen im DFD
*bereits Implementationsdetails in der MiniSpec?
*sind alle Datenflüsse des DFD im DD

== Ergebnisse der SA ==

[[Image:Ergebnisse SA.gif]]

= Konzeptionelle Datenmodellierung =

== Grundlagen ==

=== Drei-Ebenen-Architektur ===

*Die Arbeit mit Modellen erfolgt in der Informatik auf drei Ebenen.
*Für Daten ist das 3-Ebenen ANSI-SPARC-Modell (1975) relevant

[[Image:DreiEbenen SPARC.gif]]

*'''Interne Ebene''': beschreibt wie die Daten auf den externen Speichermedien z speichern sind. Festlegen der physischen Speicherstruktur.
*'''Konzeptionelle Ebene''': hardware-- und softwareneutrale Beschreibung der Daten. Dient als Basis für die Umsetzung des Datenmodells auf die externe und interne Ebene. Es entsteht das semantische Datenmodell.
*'''Externe Ebene'''. Beschreibt die Daten aus der Sicht der Benutzer. Daten welche in der konzeptionellen eeben zerlegt wurden, werden hier wieder zusammengesetzt (View, Abfrage, etc.)

=== Vorgehensweise ===

Für die Datenmodellierung hat sich folgenden Vorgehensweise durchgesetzt:

*Realitätsanalyse (Grobmodell in der Vorstudie)
*Erstellung des ERM (Detailliertes Modell in der Systemanalyse)
*Umsetzung des ERM in ein RDM (Entwurfsphase)
*Physisches Datenmodell (Realisierungsphase)

== Elemente des Entity-Relationship-Modells (ERM) ==

=== Entitäten und Eigenschaften ===
siehe Modul 170

=== Beziehungen ===
siehe Modul 170

=== Generalisierung / Spezialisierung ===
Für sich überlappende Entitätsmengen kann immer eine Menge definiert werden, welche die überlappenden Mengen umfasst. Eine solche Menge wird als Superentität bezeichnet. Das Definieren einer Superentität wird Generalisierung bezeichnet und die in einer Generalisierung auftretenden Entitätsmengen und Subentitäten lasse sich als Spezialisierung auffassen.

'''Die vier Arten der Überdeckung'''

(die folgenden Beispiele gehen vom Beispiel einer Subentität "Fotoclub" und "Sportclub aus)

'''1. Die Subentitätsmengen überlappen sich gegenseitig'''

Beispiel: Ein Mitarbeiter kann in keiner, nur einer oder in beiden Subentitäten vorhanden sein.

'''2. Die Subentitätsmengen überlappen sich gegenseitig und überdecken vollständig die Entitätsmenge der Generalisierung'''

Beispiel: Ein Mitarbeiter muss in einer oder in beiden Subentitäten vorhanden sein.

'''3. Die Subentitätsmengen sind sich gegenseitig disjunkt'''

Beispiel: Ein Mitarbeiter kann in keiner oder einer Subentitäten vorhanden sein.

'''4. Die Subentitätsmengen sind sich gegenseitig disjunkt und überdecken vollständig die Entitätsmenge der Generalisierung'''

Beispiel: Ein Mitarbeiter muss in einer, aber nicht in beiden Subentitäten vorhanden sein.

=== Assoziationen ===

Siehe Modul 170

=== Eigenschaften und Attribute ===

Siehe Modul 170

=== Aggregation ===

In bestimmten Situationen kann es erwünscht sein, dass ein Beziehungstyp selbst an einer Beziehung teilnehmen soll. Der Beziehungstyp wird dadurch zu einem komplexen Entitätstyp uminterpretiert. Der Vorgang wird häufig auch als '''Aggregation''' und der entstehende Entitätstyp als '''Assoziationstyp''' bezeichnet.

[[Image:Aggregation ERM.gif]]

Im obigen Beispiel soll der Kurs mit einer Prüfung abgeschlossen werden. Die Prüfung bezieht sich einerseits auf den Kurs und andererseits auf den teilnehmen, als auf deren Beziehung untereinander, "Teilnahme" genannt. Daher ist es notwendig die Prüfung mit der Teilnahme in Beziehung zu setzen. dies wird erreicht, indem die Beziehung als Entität aufgefasst wird.

Auch wenn in einer Beziehung zusätzliche Daten untergebracht werden sollen muss eine komplexe Beziehung als Entität aufgepasst werden. (Im Beispiel das Anmeldedatum).

= Weitere Techniken der Systemanalyse =

== Zustandsdiagramm ==

=== Beschreibung ===

Beschreibt verschiedene Zustände einer Entität/Objekt (d.h. einen möglichen Lebenszyklus) sowie die Ereignisse, Bedingungen und Aktionen welche die Übergänge (Transitionen) zwischen diesen Zuständen verursachen.

=== Notation ===

[[Image:Zustandsdiagramm-Notation.gif]]

Hinweis:
Anfangs- und Endzustand sind als besondere Zustandstypen anzusehen, da zu einem Startzustand kein Übergang stattfindet und dem Endzustand keine Zustandsänderung folgt.

Beispiel Zustandsdiagramm für die Offerterstellung des Seminar-Hotels:

[[Image:Zustandsdiagramm-Beispiel.gif]]

== Aktivitätsdiagramm ==

=== Beschreibung ===

*besteht aus Folgen von Aktivitäten. Ein Aktivität ist dabei ein einzelner Schritt in einem Verarbeitungsablauf.
*ist vergleichbar mit den bekannten Flussdiagrammen bzw. Programmablaufplänen.
*kann u.a. zur Beschreibung von prozeduralen Abläufen, Algorithmen, Geschäftsprozessen, Anwendungsfällen oder Operationen verwendet werden.
*Im Unterschied zu Flussdiagrammen ist die Darstellung paralleler Prozesse möglich.

=== Notation ===

[[Image:Aktivitaetsdiagramm Notation.gif]]

Beispiel für Seminar-Hotel

[[Image:Aktivitaetsdiagramm Beispiel.gif]]

== Entscheidungstabelle ==

*bei komplexen Entscheidungssituationen ist eine verbale oder eine grafische Darstellung oft ungenügend.
*Die Entscheidungstabelle ist ein Klassiker unter den Darstellungstechnikern und ein bewährtes Hilfsmittel um Entscheidungssituationen übersichtlich und verständlich darzustellen
*können durch Generatoren automatisch in Code verwandelt werden.

=== Grundaufbau ===

[[Image:Entscheidungstabelle Grundlagen.gif]]

=== Arten von Entscheidungstabellen ===

'''Begrenzte Entscheidungstabellen'''

Haben im Bedingungsanzeigerteil nur folgende Symbole:

*J: Bedingung muss erfüllt sein)
*N: Bedingung darf nicht erfüllt sein)
*-: Bedingung egal (Irrelevanzanzeiger)

[[Image:Begrenzte Entscheidungstabelle.gif]]

Von der vollständigen Entscheidungstabelle ET1 mit allen '''2 hoch 3 = 8 Regeln''' kommt man wie folgt zur begrenzten Entscheidungstabelle ET2:
*prüfen ob es Regeln mit identischen Aktionen gibt. Wenn ja, werde zwei dieser Regeln betrachtet und geprüft auf welche Bedingung es ankommt. Irrelevante Bedingungen werden eliminiert.
*Im Beispiel haben die regeln R3 und R4 in ET1 dieselbe Aktion. Es kommt also auf das J oder N in Bedingung B3 nicht an. Darum werden R3 und R4 in ET1 zu R3 in ET2 zusammengefasst. Anstelle des J oder N wird das "-" eingesetzt.
*Ebenso kann man leicht erkennen, dass es bei Regeln R5 bis R8 in ET1 auf Bedingung B2 und B3 nicht ankommt. --> zusammenfassen

'''Erweiterte Entscheidungstabelle'''

Unterscheiden sich von den begrenzten dadurch, dass die einzelnen Bedingungen und Aktionen nicht mehr vollständig beschrieben, sondern nur zusammen mit den Eintragungen im Bedingungs-- und Aktionsanzeigerteil eindeutig bestimmt werden.

Beispiel:
[[Image:Entscheidungstabelle erweitert.gif]]

== CRUD-Matrix ==

*ist eine Möglichkeit den Zusammenhang zwischen den Daten- und Funktionssicht herzustellen.
*kann auch eine QS-sichernde Massnahme sein.
*zeigt welche Entitäten von welchen Funktionen erstellt (create), gelesen (read), verändert (update) oder gelöscht (delete) werden.
*die Anforderungsspezifikation ist erst vollständig wenn jede Entität mindestens von einer Funktion erstelle und gelöscht werden kann.
*wenn die Funktion zum lesen fehlt, muss die Spezifikation ebenfalls näher geprüft werden.

[[Image:CRUD-Matrix.gif]]

= Grundlagen zum Entwurf =

Nachdem die Anforderungen analysiert, dokumentiert und modelliert wurde (das "Was"), soll in der nächsten Entwicklungsphase eine Entwurf des Systems erstellt werden (das "Wie")

== Einordnung des Entwurfs ==

Aufgabe des Entwerfen (Design) ist es, aus den Anforderungen eine Software-technische Lösung im Sinne eine Software-Architektur zu entwickeln. Entwerfen wird auch als "Programmieren im Grossen" bezeichnet.

Ziele des Softwareentwurfs:
*Erhöhung der Produktivität bei der Entwicklung und Wartung komplexer Systeme
*Sicherung wesentlichen Qualitätsmerkmale aus Entwicklersicht wie Wartbarkeit
*Sicherung wesentlichen Qualitätsmerkmale aus Benutzersicht wie Zuverlässigkeit.

Ergebnis des Entwurfs ist eine '''Entwurfsspezifikation''', die Beschreibung der Software-Architektur des geplanten Systems. Bevor mit den eigentlichen Entwurfsaktivitäten begonnen werden kann, müssen die Rahmenbedingungen geklärt und festgelegt werden. Ausserdem müssen eine Reihe von Entscheidungen gefällt werden welche die weitere Vorgehensweise wesentlich beeinflussen.

== Einflussfaktoren ==

*Produkteinsatz: Mandantenfähigkeit, zentraler/verteilter Betrieb, etc.
*Nichtfunktionale Anforderungen: Skalierbarkeit, Internationalisierung, etc.
*Qualitätsanforderungen: Zuverlässigkeit, Effizienz, etc..
*Zielplattform: Netzdienste, GUI-System, Datenbanken, Systemsoftware, etc.

Diese Faktoren beeinflussen sowohl die zu entwerfende Software-Architektur als auch die zu treffenden Entscheidungen bezüglich unterstützenden Systeme:

*Datenhaltung
*Benutzeroberfläche
*Hilfesystem

=== Produkteinsatz ===

bei den Einsatzbedingungen sind verschieden Aspekte zu unterscheiden welche einen wesentlichen Einfluss haben. Z.B.

*Zentrale / verteilte Systeme
*Mandantenfähigkeit

'''Zentraler / Verteilter Betrieb'''
*Client / Server Konzept

'''Mandantenfähigkeit'''
*alle Daten eines Mandanten müssen unabhängig von den anderen Mandaten gespeichert werden.

=== Nicht-funktionale Anforderungen /Qualitätsanforderungen ===

z.B.
*international --> mehrere Sprachen, verschieden Währungsformate, Mehrwertsteuerberechnungen
*verschiedene Plattformen
*Skalierbarkeit
*Zuverlässigkeit
*Effizienz

=== Zielplattform ===

*Es muss geklärt werden welche "unterstützenden Systeme" benötigt werden und ob diese auf der Zielplattform bereits existieren.
*Die Schnittstellen zu diesen System müssen klar definiert sein.
*klären ob unterstützende Systeme selber entwickelt werden müssen.

fast alle Anwendungen benötigen eine Datenhaltung. Dafür gibt es im Wesentlichen vier Konzepte:
*"flache" Dateien (flat files). Filesystem des jeweiligen Betriebssystem
*hierarchische DB (nicht mehr aktuelle, aber aus Performancegründen interessant wo sehr grosse Datenmengen zu verwalten sind)
*relationale DB (RDBMS)
*objektorientierte DB (ODBMS) (aktuell nur für kleine Datenmengen einsetzbar)

Weitere Faktoren:
*Datenhaltung auf einem Server oder verteilt auf mehrere Plattformen
*Art und Weise wie die Benutzeroberfläche realisiert werden soll (u.a. abhängig von der Programmiersprache)
*soll ein eigenständiges Hilfesystem eingesetzt werden oder stellt das OS schon etwas zur Verfügung.

Generelles Ziel aller Entscheidungen:
*möglichst viele Dienstleistungen auf hohem Abstraktionsniveau von anderen Systemen in Anspruch nehmen.

== Aufgaben des Entwurfs ==

*Erstellen einer konkreten Software-Architektur für das zu entwerfende Produkt, welche funktionalen und nicht-funktionalen Anforderungen sowie allgemeine und produktespezifische Qualitätsanforderungen erfüllt und die Schnittstellen zur Umgebung versorgt.

=== Software-Architektur ===

*Beschreibt die Struktur des Systems durch Komponenten und ihre Beziehung untereinander
*Eine Komponente ist ein abgegrenzter Teil eines Systems. Sie dient als Baustein für die physikalische Struktur einer Anwendung.
*Beispiel für Komponenten: Module, Funktionen, Prozeduren, abstrakte Datentypen.
*Eine Beziehung kann jede mögliche Art von Verbindung zwischen den Komponenten sein

Beispiel für Beziehungen:
*Aufruf von Funktionen durch andere Funktionen
*Austausch von Daten zwischen Komponenten

=== Modularisierung ===

*ist die Aufgliederung eines Systems in mehrere Teile (Module, Komponenten)

Ein Modul ist ein SW-Baustein der folgende Eigenschaften hat:
*Darstellung einer funktionalen Einheit oder zusammengehörende Funktionsgruppen
*Weitgehend Kontextunabhängig, d.h., ein Modul ist in sich abgeschlossen und unabhängig von der Umgebung entwickelbar, prüfbar und einsetzbar.
*Definierte Schnittstelle für die Verwendung des Moduls
*handlich, überschaubar, verständlich.

Vorteile:
*Einfache Änderbarkeit/Austauschbarkeit
*Verbesserung der Wartbarkeit
*Erhöhung der Wiederverwendbarkeit
*Erleichterung der Standardisierung
*Verbesserung der Überprüfbarkeit
*Erleichterung der Arbeitsorganisation

'''Hinweis''': Zur Modularisierung gehört auch das Prinzip der Kapselung.

=== Schichtenarchitektur ===

Wenn eine Software viele Komponenten hat, ist eine stärkere Strukturierung sinnvoll. Diese '''Schichtenarchitektur''' kann wie folgt dargestellt werden:

[[Image:Schichtenarchitektur.gif]]

Gliedert man eine Anwendung in Benutzeroberfläche, eigentliche Anwendung und Datenhaltung, dann erhält man eine '''Drei-Schichten-Anwendungsarchitektur''' (3-tier-architecture)

= Strukturierter Entwurf =

Ein in der Definitionsphase (=Analysephase) erstelltest SA_Modell kann mit Hilfe von Transformationsregeln in eine strukturierte Software-Architektur umgewandelt werden.

Ein '''strukturierter Entwurf''' ist der planvolle, systematische Ansatz, um um zum Entwurf eines geplanten System-Systems zu kommen.

Ziel des strukturierten Entwurfs:
*eine konkrete Software-Architektur zu erstellen die aus hierarchisch angeordneten funktionalen Modulen besteht. Zur Beschreibung des Entwurfs werden Strukturdiagramme und Modulspezifikationen verwendet.

Mit Hilfe des strukturierten Entwurfs entstehen Kriterien zur Beurteilung der SW-Qualität.

== Grundsätze des strukturierten Entwurfs ==

Vorgehensweise:
*Aufteilung in Module
*hierarchische Organisation der Module

=== Aufteilung in Module ===

Ein System wird zunächst in Black Boxes aufgeteilt. Eigenschaften der Blackbox:

*Eingabewerte sind bekannt
*Ausgabewerte sind bekannt
*Die Funktion ist bekannt
*Es ist nicht bekannt wie die Funktion ausgeführt wird.

Vorteile von Systemen, dies aus Black Boxes zusammengesetzt sind:

*einfach aufgebaut
*einfach zu testen
*können einfach repariert werden
*leicht zu verstehen
*leicht veränderbar

Die Einteilung in Black Boxes beim strukturierten Design geschieht nach folgenden Gesichtspunkten:

*jede Black Box löst einen genau definierten teil des Problems
*Die Aufteilung geschieht so, dass dabei jede entstehende Funktion leicht zu verstehen ist.
*Die Verbindung zwischen Blaxk Boxes ist dann sinnvoll, wenn sie einer Verbindung zwischen Teilern der Problemstellung entspricht.
*Die Verbindung zwischen Black Boxes sollte so einfach sein, dass sie unabhängig wie möglich voneinander sind.

Zusammengefasst: Dir Struktur der Aufgabenstellung definiert die Struktur der Lösung und nicht umgekehrt.

=== Organisation in Hierarchien ===

Wie bei hierarchischer Struktur einer Firma: In den oberen Stellen werden Aufgaben wie Planung, Koordination whregenommen während die unteren Stellen die Teilaufgaben erledigen. (Aufgaben werden von oben nach unten delegiert)

== Funktionale Abstraktion ==

Ein funktionales Modul besitzt folgende Eigenschaften:

*Es ist aktiv bzw. aktionsorientiert, d.h. es "tut" etwas.
*Es besitzt ein Transformationsverhalten, d.h. Eingabedaten werden in Ausgabedaten transformiert.
*Identische Eingabedaten führen immer zu identischen Ausgabedaten, d.h. ein funktionales Modul besetzt '''kein''' internes Gedächtnis.

Aufgaben:
*Steuerungs- Koordinationsaufgaben (z.B. Hauptprogramm)
*Transformationsaufgaben (z.B. Compiler)
*Auswertungsaufgaben
*Hilfsaufgaben

=== Modulspezifikation ===

Damit eine funktionales Modul im Rahmen eines Entwurfs eingesetzt werden kann, muss seine Schnittstelle spezifiziert werden:

*Aufgabenbeschreibung
*Eingabeparamater (inkl. Datentyp)
*Ausgabeparameter (inkl. Datentyp)
*evtl. Vorausssetzungen und Vorbedingungen
*evtl. Bedingung die nach der Anwednung geldent
*verhalten bei inkorrekten Eingabewerten oder Fehlfunktion des zugrunde liegenden Basissystems

=== Strukturdiagramm ===

Bestehen aus:
*Rechtecke die funktionale Module darstellen
*Aufruflinien zwischen Rechtecken welche die Aufrufhierarchie festlegen
*Datenpfeile beschreiben die Kommunikation zwischen Modulen

[[Image:Notation-Strukturdiagramm.gif]]

*Der Modulname soll die Funktion des Moduls beschreiben, die si für das rufende Modul erledigt.

Die Datenpfeile werden mit den Namen der aktuellen Parameter beschriftet:
*Ein Pfeil mit weissem Kreis beschreibt eine Datenkommunikation (Daten werden übergeben)
*Ein Pfeil mit schwarzem Pfeil beschreibt eine Status-Information (flag). (z.B. Dateiende). Eine eigentliche Verarbeitung der Information findet nicht wirklich statt.

Bereits vorhanden, zur Wiederverwendung vorgesehen Module werden wie folgt durch Doppellinien an den Rändern gekennzeichnet.

[[Image:Strukturdiagramm-Beispiel.gif]]

=== Entwurf der Modul-Inneren ====

Anschliessen wird das Modul-Innere mittels Pseudocde oder anderen Mitteln den Programmentwurfs im Detail entworfen. Mögliche Mittel:

*Jackson-Diagramm
*Nassi-Shneidermann-Diagramm
*Programmablaufplan

'''Hinweis''': Das Modul-Innere mit einer der genannten Techniker zu entwerfen ist nur bei relativ komplexen Modulen sinnvoll. Ansonsten ist es üblich aus den Vorgaben der MiniSpec direkt eine Funktion oder Teilfunktion zu realisieren.

== Qualitätskriterien ==

Wichtigste Ziele:

*Kopplung zwischen Modulen zu minimieren
*Bindung in Modulen zu maximieren

=== Kopplung ===

Module müssen so unabhängig wie möglich voneinander sein. Gründe:

*geringere Gefahr von Fernwirkungen
*keine Änderungen an anderen Modulen wenn an einem Modul etwas geändert wird.
*interne Details sollen anderen Modulen nicht bekannt sein
*System soll einfach und verständliche bleiben

=== Bindung ===

Bindung ist der Grad der funktionalen Zusammengehörigkeit der Elemente. Für ein gutes Moduldesign muss die Bindung maximiert werden. Jedes Modul soll ein bestimmte Aufgabe erledigen, diese aber komplett.

Ein Modul besitzt '''normale Bindung''' wenn es eine oder mehrere Funktionen umfasst, die inhaltlich eng zusammengehören und die mindestens auf einer gemeinsamen Datenstruktur operieren, die lokale definiert oder explizit als Parameter übergeben wird.

= Modularer Entwurf =

Der modulare Entwurf verwendet neben der "funktionalen Abstraktion" die "Datenabstraktion". Zur Beschreibung des Entwurfs werden Grafiken und Modulspezifikationen verwendet.

=== Datenabstraktion ==

Ein funktionales Modul funktionieren bei jedem Aufruf genau gleich (weil es kein Gedächtnis hat) Dies führt zu einer Reihen von Probleme. z.B. wenn der Seed eines Zufallsgenerator "geheim" gespeichert werden soll. Lösung: Seed wird im Modul als "private Daten" gehalten.

Wenn in einem Modul Daten gehalten werden, haben wir es mit einer Datenabstraktion zu tun. Wenn das Modul ein Gedächtnis hat, haben wird es mit einem Datenobjekt zu tun. Es lassen sich zwei Grade der Datenabstraktion unterscheiden.

*abstrakte Datenobjekte
*abstrakte Datentypen (ADT)

== Abstrakte Datenobjekte ==

entspricht weitgehend einem Datenobjekt in der objektorientierten Softwareentwicklung

== Abstrakte Datentypen ==

entspricht weitgehend eine Objekt-Klasse

= Entwurf von verteilten Modulen =

bei einer verteilten Architektur läuft eine Funktion in mehreren schichten ab. Es ist daher notwendig diese so in Module aufzuteilen, dass in den Schichten zugeordnet werden können. Die Verteilung muss dabei derart vorgenommen werden, dass für jedes Modul die geeignete Plattform gewählt wird.

'''Hinweis''': Ein Modul sollte nur zu genau einer Schicht gehören. Würde man die Funktionalität mehrerer Schichten in ein einziges Modul packen, würde dies dem Prinzip der losen Kopplung widersprechen.

== Die drei Schichten ==

*Präsentationslogik
*Geschäftslogik
*Datenlogik

=== Präsentationslogik (PL) ===

*Benutzerschnittstelle: GUI, spezielle Ein- Ausgabegerät z.B. Handy
*Systemschnittstellen: automatische Datenübertragungen über Schnittstellen zu anderen Systeme ohne Beteiligung von Benutzern.

=== Geschäftslogik (GL) ===

=== Datenlogik (DL) ===

sorgt für den Zugriff auf persistente Daten. Ebenso kann die Einhaltung der Datenschutz- und Sicherheitskonzepte in Datenlogik-Modulen gekapselt werden.

=== Transaktionslogik (TL) ===
Manchmal wird von einer vierten Schicht gesprochen, der TL.

== Vorgehensweise ==
Wie können die Module in einer 3-Schicht-Architektur bestimmt werden?

=== Module bestimmen ===

*Im Datenflussdiagramm suchen wir alle Schnittstellenpfeile und zu jedem Schnittstellenpfeil definieren wir ein PL-Modul.
*Im DFD suchen wir alle Pfeile von und zu Datenspeicher; zu jedem Datenspeicher-Pfeil definieren wir ein DL-Modul.
*Den Rest der Logik packen wir in einen GL-Modul

Hinweis: Beim Aufteilen in Module ist darauf zu achten, dass es sich um Module handelt welche bereits an anderer Stelle identifiziert worden sind. Damit wird die Wiederverwendbarkeit angestrebt.

=== Vorgefertigte Module verwenden ===

Die Abwicklung der Transaktionen wird gewöhnlich^von einem Transaktionsmonitor gesteuert. Dieser übernimmt einmal die Kommunikation mit dem Client und anderseits überwacht er die Durchführung der physischen Transaktion auf der DB. Daher kann sich der Anwendungsprogrammierer darauf konzentrieren die Geschäftslogik zu programmieren.

Die '''Geschäftslogik ''' wird gewöhnlich im '''Applikations-Server''' untergebracht. Auf dem Markt angebotene Applikations-Server bieten Dienste an, die Transaktionen koordinieren, die Last verteilen, für Sicherheit sorgen und Web-/GUI-Schnittstellen bedienen. Transaktionssteuerung ist einer der wichtigsten Funktionalitäten, den damit lässt sich die Konsistenz der Daten und Abläufe sicherstellen.

= Entwurf der Benutzerinteraktion =

Informatiker FA M166 Zusammenfassung

2019-08-01T13:18:55Z

Christian: Created page with "== Einleitung == Ein Unternehmen ist vielen Risiken ausgesetzt. Die Informatik ist ein zentrales internes Risiko. Kosten für Sicherheit steigen exponentiell zum Grad der Sic..."

== Einleitung ==

Ein Unternehmen ist vielen Risiken ausgesetzt. Die Informatik ist ein zentrales internes Risiko. Kosten für Sicherheit steigen exponentiell zum Grad der Sicherheit. „IT-Grundschutz“ ermöglicht mit relativ wenig Aufwand ein mittleres bis hohes Mass an Sicherheit.

Das Modul dient zum Erwerb folgender Kompetenzen
*Infrastruktur identifizieren
*Gefährdungslage feststelle und geeignete Schutzmassnahmen ableiten (organisatorische, personelle, infrastrukturelle, technische)
*Sicherheitskonzept für einen IT-Grundschutz erstellen und nachführen.

== 1 Richtlinien und Grundbegriffe ==

=== 1.1 Wichtige Richtlinien ===

*Grundschutzhandbuch
*ISO/IEC 17799
*Datenschutzgesetz
*Strafgesetzbuch

'''IT Grundschutzhandbuch'''
Ziel: Durch standardisierte Sicherheitsmassnahmen ein standardisiertes Sicherheitsniveau aufbauen welches für sensible Bereiche ausbaubar ist. Das Grundschutzhandbuch behandelt Bestimmungen welche ein mittleres bis hohes Mass an Sicherheit gewährleisten. Kataloge mit Sicherheitsmassnahmen für folgende Bereiche sind angeführt.

*Infrastruktur
*Organisation
*Personal
*Hard- und Software
*Kommunikation
*Notfallvorsorge

Vorgeschlagener Ablauf für Aufbau des Grundschutzes

*Strukturanalyse
*Feststellen des Schutzbedarfs
*Modellieren des Grundschutzes
*Basis Sicherheitscheck
*Ergänzende Sicherheitsanalyse
*Realisierung von Sicherheitsmassnahmen

'''Datenschutzgesetz'''
Ziel des Datenschutzgesetz ist der Schutz des Persönlichkeitsrechts. Personenbezogene Daten müssen vor unzulässiger Einsichtnahmen, Verarbeitung und Verbreitung geschützt werden.

'''Strafgesetzbuch'''
Damit eine strafrechtliche Verfolgung eingeleitet werden kann, muss der Geschädigte belegen können, dass er Schutzmassnahmen angewendet hat und dass er die Sorgfaltspflicht wahrgenommen hat.
Das Strafgesetzbuch gibt Hinweise auf di rechtliche Verantwortung bei der Verarbeitung und Aufbewahrung von Daten (Beweisführung)

=== 1.2 Merkmale der IT-Sicherheit ===

*Vertraulichkeit
*Verfügbarkeit
*Integrität
*Verbindlichkeit

'''Vertraulichkeit'''
Vertraulichkeit bedeutet, dass sichergestellt werden muss, dass nur Berechtige Zugriff auf vertrauliche Daten haben. Dies gilt z.b. auch für Logdateien.

'''Verfügbarkeit'''
Umfasst alle Kriterien für die Verfügbarkeit (Availability) von Daten. Z.B. Wartezeiten, Geschwindigkeit.

'''Integrität'''
Die Information muss vollständig, korrekt und unverfälscht ist. Die Daten kommen ausserdem von der Person von der ich sie erwarte. Das Programm macht das was man von ihm erwartet.

'''Verbindlichkeit'''
Wenn zwei Personen einen Vertrag abschliessen ist dieser verbindlich. In der IT ist dies nicht so einfach. Ist z.B. ein Email rechtsgültig?

Aspekte der Verbindlichkeit
*Einhaltung gesetzliche und vertraglicher Bedingungen
*Problem der Anerkennung des Empfangs von Informationen
*Nachweisbarkeit von Kommunikationsvorgängen
*Die juristische Akzeptanz von Rechtsgeschäften welche mit IT-Mitteln zustande gekommen sind.

(wo gehört der folgende Absatz hin?)
Begriffe der Risikoanalyse
- Bedrohung
- Verletzbarkeit
- Risiko
- Schaden
- Eintrittswahrscheinlichkeit
- Sicherheitsmassnahmen

=== Weitere Begriffe der IT-Sicherheit ===

'''Bedrohung'''
Eine Bedrohung (Threat) stellt ein Ereignis darf welches zu einem Verlust führen kann. Bedrohungen könne in folgende Kategorien unterteilt werden
*Menschliches Versagen
*Vorsätzliche Handlung
*Technisches Versagen
*Höhere Gewalt
*Organisatorische Mängel (Fehlende Konzepte, Verantwortungen nicht definiert). Hinter organisatorischen Mängeln steckt immer menschliches Versagen.

'''Verletzbarkeit'''
Die Verletzbarkeit (Vulnerability) beschreibt einen Mangel oder eine Anfälligkeit an einem Objekt . (Potenzial welches zu einem Verlust führen kann). Die Verletzbarkeit muss getrennt auf die vier Hauptmerkmale der IT-Sicherheit beurteilt werden (Vertraulichkeit, Verfügbarkeit, Integrität, Verbindlichkeit)

'''Risiko'''

Das Risiko ist die Kombination aus Bedrohung und Verletzbarkeit bezogen auf ein Objekt.
Beispiel (fiktiv)
*Bedrohung: Webserver e-learner
*Verwundbarkeit: Sicherheitsleck in PHP
Beides zusammen führt zu einem '''Risiko'''.

'''Schaden'''
Schadenskategorien:
*Direkte Schäden (z.b an Hardware, Software, Datenträgern oder Daten)
*Indirekte Schäden (Z.B. Kosten für Datenrekonstruktion, Personalaufwand)
*Folgekosten (z.B. entgangene Gewinne wegen Produktionsunterbruch, Schadenersatzansprüche Dritter)

'''Eintrittswahrscheinlichkeit'''
Arten von Wahrscheinlichkeiten:
*Objektive, messbare und kalkulierbare (z.B. 50-zu-50 Chance bei einem Münzenwurf)
*Subjektive, nicht messbare und geschätzte Wahrscheinlichkeit (z.B. Eintritt einer Krankheit aufgrund einer Diagnose von Symptomen)
*Objektive Unmöglichkeit eine Wahrscheinlichkeit zu ermitteln (z.B. Ort eines bestimmten teils nach einem Knetvorgang)

Für die Berechnung von Eintrittswahrscheinlichkeiten werden oft Statistiken aus der Versicherungsbranche herbeigezogen.

'''Sicherheitsmassnahmen'''
Dienen zur Abwehr oder Minderung eines möglichen Schaden. Sie können jedoch viel Kosten und müssen somit der Eintrittswahrscheinlichkeit bzw. dem Risiko angepasst werden.

== 2 Sicherheitsvorgaben aus dem Strafrecht ==

Das DSG schützt natürlich und juristische Personen vor Persönlichkeitsverletzungen.
Überall wo personenbezogene Daten gespeichert oder bearbeitet werden sind die Regeln des DSG (Datenschutzgesetz) zu beachten. Egal ob elektronisch oder auf Papier gespeichert wird.

Der Begriff „Datensammlung“ wird vom DSG als Bestand von Personendaten definiert, der so aufgebaut ist, dass die Daten nach betroffenen Personen erschliessbar sind.

Diese Personendaten enthalten insbesondere Informationen über:
*Religion, Weltanschauung, Politik, Gewerkschaft
*Gesundheit
*Intimsphäre
*Rassenzugehörigkeit
*Massnahmen der sozialen Hilfe
*Administrative oder strafrechtliche Verfolgung und Sanktion

'''Anmeldung einer Datensammlung'''

Der Eidgenössische Datenschutzbeauftragte führt ein Register dieser Datensammlungen. Datensammlungen dieser Art müssen angemeldet werden.

Ausnahmen:
*Wenn die Verarbeitung gesetzlich angeordnet wurde (ausser Bundesorgane: diese müssen alle Sammlungen anmelden)
*Wenn die Betroffenen angefragt wurden ob die Informationen verwendet werden dürfen.

Personendaten dürfen nur zu dem Zweck verwendet welcher bei der Datenbeschaffung angegeben wurde.
Jeder Betroffenen hat das Recht die über ihn gesammelten Daten einzusehen, auch wenn diese nicht angemeldet werden mussten. Weiter hat dieser das Recht die Korrektur an falschen Daten zu verlangen.

'''Schutz der Daten'''

Personendaten müssen durch angemessene organisatorische und technische Massnahmen gegen unbefugten Zugriff geschützt werden.

Eigenschaften der Massnahmen:
*Verhältnismässig
*Müssen dem Zweck der Bearbeitung, Art und Umfang der Bearbeitung und den möglichen Risiken entsprechen.
*Müssen dem gegenwärtigen Stand der Technik entsprechen.

Ein Sicherheitskonzept gemäss IT-Grundschutz erfüllt diese Anforderungen weitgehend.

Übersicht der erwarteten Massnahmen:
*Zugangskontrolle: Unbefugten Personen ist der Zutritt zu Räumen zu verwehren in den Personendaten verarbeitet werden.
*Datenträgerkontrolle: Unbefugten ist der Zugriff auf die Datenträger zu verunmöglichen.
*Transportkontrolle: Bei der Bekanntgaben von Personendaten oder deren Transport (elektronisch oder physisch) ist zu verhindern, dass Unbefugte Zugriff erhalten.
*Bekanntgabekontrolle: Berechtigte Datenempfänger müssen identifiziert werden können.
*Speicherkontrolle: Unbefugte Eingabe Speicherung, Veränderung. Löschung oder Einsichtnahme ist zu verhindern. (in Bezug auf Speichermedium)
*Benutzerkontrolle: Die Benutzung von Datenverarbeitungssystemen durch Unbefugte ist zu verhindern.
*Zugriffskontrolle: Zugriff auf die Daten darf nur den Personen gegeben werden welche diese für die Erfüllung Ihrer Arbeit benötigen.
*Eingabekontrolle: Es muss nachträglich geprüft werden können, welche Personendaten, zu welcher Zeit und von welcher Person eingegeben wurden.

'''Strafbestimmungen des Datenschutzgesetzes'''

Bei Verletzung können Haft und Busse die Folge sein. Gilt sowohl während der Bearbeitungs- und Aufbewahrungszeit aber auch danach (Schweigepflicht)
Kunstgriff für Umgehung des DSG: Daten „entpersonifizieren“. Schlüssel zur Identifikation des Benutzers wird in einer anderen DB gespeichert. So muss hauptsächlich nur diese geschützt werden.

'''Bedrohung durch Computerkriminalität'''

Das Gesetz unterscheidet folgende strafbare Handlungen.
*Computerkriminalität: Computer ist das Ziel oder die Waffe zu einer tat. Meistens muss eine rechtswidrige Vermögensverletzung vorliegen. (Datenveränderung, Zerstörung, Sabotage, Datenerlangung, Spionage)
*Computerbetrug: Unbefugtes Beeinflussen von Ergebnissen durch unrichtige Programme, Einwirken auf das Programm, verwenden unrichtiger Daten. Es muss ein Vermögensvorteil für sich oder Dritte entstehen.
*Computerspionage: Die unberechtigte Aneignung von Daten.
*Computersabotage: Die vorsätzliche Beeinträchtigung von Daten oder HW.
*Computermissbrauch Erschleichung einer Leistung: Die unbefugte Nutzung von Systeme n mit der Absicht sich oder Dritten einen Vermögensvorteil zu verschaffen.

'''Bestimmungen auf dem Strafrecht'''

Auflistung von relevanten Artikeln aus dem Strafgesetzbuch . (siehe Buch)
Eine Geschädigter muss aufzeigen können, dass er angemessen Massnahmen zur Sicherung der Systems vorgenommen hat und muss dies belegen können.
Es können recht hohe Strafen ausgesprochen werden.
Das Datenschutzgesetz und das Strafrecht setzen das Vorhandensein einer Sicherheitsstrategie voraus.
Jedes Unternehmen arbeitet mit mindestens zwei schützenswerten Daten: Personendaten und Kundendaten.

== 3. Grundprinzip der Risikoanalyse ==

=== 3.1 Systemabgrenzung ===
Als erstes wird das ganze IT-System in einzelne Bereiche (Webserver, Extranet, LAN etc.) unterteilt. Dadurch wird die Komplexität reduziert. Ausserdem weisen spezifische Bereiche besondere Sicherheitsaspekte auf. Danach werden die Komponenten der abgegrenzten Bereiche aufgelistet und kurz beschrieben.

Beispiel:

{| border="1"
! Komponente!! Beschreibung
|-
| Apache || Webserver-Software für Kundenwebs
|-
| VMWare || Virtualisierungs-Software auf Host
|-
| Riker.adabis.ch || Server-Hardware für Apache
|-
| Switch || Verbindung zu Internet
|}

=== 3.2 Definition des Datenbestandes ===
Innerhalb des untersuchten Bereiches sind Datenbestände vorhanden. Die Risikoanalyse betrachtet vorwiegend die Gefährdung dieser Bestände. Z.B. Adabis Kundendaten (inkl. Passwörter) und Kundenwebs.

=== 3.3 Definition der Verletzbarkeit ===

Die Datenbestände werden Bedrohungen der Informatik gegenübergestellt.

{| border="1"
! Grundbedrohung !! Mitarbeiterdaten !! Geschäftszahlen !! Kundendaten
|-
| Vertraulichkeit || 1) Es dürfen keine Mitarbeiterdaten die Personalabteilung verlassen || Keine Verletzbarkeit || 2) Datenschutzgesetz
|-
| Verfügbarkeit || Keine Verletzbarkeit || 3) Keine Führung des Unternehmens möglich || 4) Produktionsausfall
|-
| Integrität || Keine Verletzbarkeit || 5) Führung auf Grund falscher Tatsachen || 6) Falsches Versenden von Artikeln
|-
| Verbindlichkeit || Keine Verletzbarkeit || Keine Verletzbarkeit || Keine Verletzbarkeit
|}

=== 3.4 Definition der Bedrohung ===
Es wird ein Bedrohungskatalog erstellt. Folgende Bedrohungen können z.B. genannt werden: Stromausfall, Hardwareausfall, Hackerangriff.

=== 3.5 Risikoanalyse ===
Nun erfolgt die eigentlich Ermittlung des Risikos (Bedrohung + Verletzbarkeit = Risiko)

Verletzlichkeit Bedrohung

{| border="1"
! Verletzlichkeit !! colspan="3" | Bedrohung
|-
! Nr !! Stromausfall !! Festplattenausfall !! Hackerangriff
|-
| 1) Vertraulichkeit Mitarbeiterdaten || Kein Risiko || Kein Risiko || a) Hacker kann Daten einsehen
|-
| 2) Vertraulichkeit Kundendaten || Kein Risiko || Kein Risiko || b) Hacker kann Daten einsehen
|-
| 3) Verfügbarkeit Geschäftsdaten || c) System läuft nicht mehr || d) System läuft nicht mehr || e) Hacker kann System manipulieren
|-
| - - - || || ||
|}

=== 3.6 Schadensausmass und Eintrittswahrscheinlichkeit ===
Das wahrscheinliche Schadensausmass pro Jahr gibt Aufschluss über die höher der Sicherheitsmassnahmen. Wenn kein Frankenbetrag bezifferbar ist, können qualitative Aussagen gemacht werden (niedrig, mittel, hoch, existenzbedrohend)

{| border="1"
! Nr !! Definition der Risiken !! Schadensgrösse !! Wahrscheinlichkeit !! Schaden
|-
| a || Mitarbeiterdaten sind zu wenige gegen Hackerangriffe geschützt || Mittel || Klein, da nur intern zugreifbar || Klein
|-
| b || Kundendaten sind zu wenige gegen Hackerangriffe geschützt || Gross || Gross, da über WWW erreichbar || Gross
|-
| c || Geschäftszahlen sind bei Stromausfall nicht vorhanden || Klein, da keine Arbeitsplätze mehr laufen || Gross || Klein
|-
| d || Geschäftszahlen sind bei Systemausfall nicht vorhanden || Gross, da längerer Ausfall || Gross || Gross
|}

(Schadensgrösse * Wahrscheinlichkeit = Schaden)

=== 3.7 Sicherheitsmassnahmen ===

Zum Schluss werden die einzelnen Komponenten ermittelt die beim entsprechenden Risiko eine Rolle spielen. Pro Komponenten werden dann Massnahmen definiert

{| border="1"
! Risiko Nr !! Schaden !! Komponente!! Definition der Sicherheitsmassnahme
|-
| a || Klein || Applikation 1 || Benutzer-ID und Passwort + Rollen
|-
| a || Klein || Server 1 || Passwortschutz + Physischer Zugriffsschutz
|-
| a || Klein || Router 1 || Physischer Zugriffsschutz
|-
| b || Gross || Server 2 || Passwortschutz + Zugriffsschutz zum Server + Firewall + Automatische Logfilekontrolle
|}

'''Zusammenfassung:'''
Die Bedrohung und die Verletzbarkeit gegeben ein Risiko. Beim Eintreten des Risiko entsteht ein Schaden. Die Eintrittswahrscheinlichkeit und die Schadenshöhe ergeben das tatsächliche Schadensausmass. Je nach Schadenshöhe werden dann die Massnahmen definiert.

== 4 Allgemeine Gefährdungen ==

Gefährdungen (Bedrohungen) können in folgende Bedrohungsbilder unterteilt werden:
*Höhere Gewalt
*Menschliche Fehlhandlung
*Technisches Versagen
*Vorsätzliche Gewalt
*Organisatorische Mängel

=== 4.1 Höhere Gewalt ===
Umwelteinflüsse, Naturkatastrophen. Um sich gegen höhere Gewalt zu schützen sind meistens Massnahmen im Infrastrukturbereich nötig.

=== 4.2 Menschliche Fehlhandlungen ===
Hier wird davon ausgegangen, dass keine vorsätzliche Absicht vorliegt. Hauptursachen: Unwissenheit, Unachtsamkeit, zu grosse Komplexität. Massnahmen: Schulung, sichere Applikationen, umfangreiche Tests, restiriktive Zugangsberechtigungen.

=== 4.3 Technisches Versagen ===
Selbsterklärend. Massnahmen: Redundanzen, Wartungsverträge, Notfallkonzepte, Hardware und Software intensiv testen

=== 4.4 Vorsätzliche Gewalt ===
Beinhaltet das bewusste Zuführen von Schaden. Massnahmen: physische Zutrittskontrolle, Zugangskontrolle (Passwörter), Netzwerksicherheit (Firewall), Systemsicherheit (Abschalten nicht benötigter Dienste)

=== 4.5 Organisatorische Mängel ===
Keine Verantworten für Tätigkeiten geregelt. Tätigkeiten werden nicht kontrolliert. Prozesse werden nicht gelebt. Hinter einem organisatorischen Mangel steckt immer menschliches Fehlverhalten. Massnahmen: Konzepte, schaffen neuer Stellen, Zuordnen von Aufgaben und Verantwortlichkeiten, Policies, Weisungen

Im Rahmen von IT-Sicherheit gilt es die Bedrohungsbilder
*höhere Gewalt,
*menschliche Fehlhandlungen,
*technisches Versagen,
*vorsätzliche Handlungen und
*organisatorische Mängel
auseinander halten zu können und auch zu wissen, was hinter den einzelnen Begriffen steckt. Es ist wichtig, Gefährdungen nach diesem Raster unterscheiden zu können, da dadurch bereits Hinweise auf die nötigen Gegenmassnahmen gegeben werden.

== 5 Sicherheitsmassnahmen im Überblick ==

Massnahmen können in folgende Bereiche unterteilt werden:

*Infrastruktur (bauliche Massnahmen, Zutrittskontrolle)
*Personal (Schulung, Weisungen)
*Organisation (Strategien, Abläufe, Konzepte)
*Hardware und Software (übliche technische Massnahmen)
*Kommunikation (Protokolle, Verschlüsselung, Netzwerkdienste)
*Notfallvorsorge (Backup, Notfallkonzepte)

=== 5.1 Infrastruktur ===

Massnahmen gegen höhere Gewalt, Elementarschäden (Feuer, Wasser), gegen vorsätzliche Handlungen wie Diebstahl.

=== 5.2 Personal===

jeder Mitarbeiter ist ein Risiko. Unwissenheit und Fahrlässigkeit sind die häufigste Ursache für Schadensereignisse.

Massnahmen:
*Benutzer an Sorgfaltspflicht erinnern
*Weisungen (kommunizieren!) Bei Bedarf sollen Mitarbeiter das Lesen der Weisung schriftlich bestätigen.

=== 5.3 Organisation ===

Hier werden Massnahmen zusammengefasst welche hauptsächlich auf Unternehmensebene geregelt werden müssen. Diese sind erst wirksam wenn sie unternehmsweit gleich gelebt werden.

z.B. Umgang mit..
*Datenschutzgesetz
*Datenträgern
*Virenschutz
*Passwortgebrauch
*Aufbewahrung von Daten

'''Wichtig''': Die Einführung der IT-Sicherheit als ganzes ist die wichtigste Massnahme

Ein weiterer wichtiger Punkt ist, dass alle Verantwortlichkeiten und Aufgaben einem Verantwortlichen zugewiesen sind und dieser die Verantwortung wahrnimmt.
Alle Aufgaben müssen zugeordnet und periodisch überprüft werden.

=== 5.4 Hardware und Software ===

Unter diesem bereich werden wohl die bekanntesten Massnahmen zusammengefasst

*Passwörter
*Verschlüsselung
*Loginprozeduren

Bekannte Sicherheitslöcher müssen mit entsprechenden Massnahmen kompensiert werden. Sicherheitsfunktionen welche von der Grundinstallation nicht vorhanden sind, müssen nachinstalliert werden.

=== 5.5 Kommunikation ===

Sicherheitsmassnahmen bei Übertragungsprotokollen und Übertragungsmedien

*Sicherung der Kupfer- und Glasfaser Leitungen (z.B. bei "öffentlichem Grund")

=== 5.6 Notfallvorsorge===

Hier wird definiert was geschieht wenn ein Risiko wirklich eintrifft

*Wie macht man ein System möglichst schnell wieder lauffähig
*Datensicherung
*Notfallkonzept

Der Wiederanlauf muss nicht nur geplant, sondern von Zeit zu Zeit verifiziert und getestet werden.

Ein Sicherheitskonzept (Summe aller Massnahmen) lebt indem technische Neuerungen laufend eingebaut und bekannte Sicherheitslöcher laufend behoben werden.

== 6 Grundgedanke IT-Grundschutz ==

Der IT-Grundschutz beinhaltet technische und organisatorische Massnahmen und Risiken effizient abzuwehren.

Nicht jedes Unternehmen soll Rad neu erfinden müssen. Es bestehen bei den Unternehmen keine so grossen Unterschiede bezüglich Bedrohung und Schwachstellen. Deshalb können Massnahmen standardisiert werden.

*Ein IT System enthält typische Komponenten (Clients, Server, Betriebssystem)
*Bedrohungen und Riskieren und Eintrittswahrscheinlichkeiten lassen sich pauschalisieren
*Der Aufwand kann minimiert werden wenn Standards verwendet werden können.

Daraus resultieren folgende Vorteile:
*Einfache Anwendung anstatt teurer und komplizierten Analysen
*Praxiserprobt
*Erweiterbarkeit und Aktualisierbarkeit

=== 6.1 IT-Grundschutz Bausteine ===

Die "Bausteine" sind das Kernstück des Grundschutzhandbuches. Hinter jedem Baustein stehen vordefinierte Massnahmen. Beispiel "PC unter Windows NT"

'''Beschreibung''': Es wird beschrieben, dass Vista der Nachfolger von XP ist und auf Grund der starken Verbreitung von Windows System stark gefährdet ist. Weiter werden sie mit Vista eingeführte Sicherheitsmerkmale angesprochen (Protected Mode, UAC, Bitlocker etc.)

'''Gefährdungslage''': es werden für die folgenden typischen Gefährdungen Annahmen getroffen. Höhere Gewalt, Organisatorische Mängel, Menschliche Fehlhandlungen, Technisches Versagen, Vorsätzliche Handlungen

'''Massnahmenempfehlungen''': Es werden unter anderem Empfehlungen zur Version, Gruppenrichtlinien, Automatischen Updates und diversen Dokumenten abgegeben.

Die Bausteine sind den folgenden Schichten zugeordnet

*Schicht 1: Übergreifende Aspekte
*Schicht 2: Infrastruktur
*Schicht 3: IT-Systeme
*Schicht 4: Netz
*Schicht 5: IT-Anwendungen

'''Schicht 1''' beschreibt alles Aspekte welche für ein Unternehmen einheitlich geregelt werden müssen. Beispiel: Sicherheitsmanagement, Organsisation, Datensicherungskonzept, Virenschutz.

'''Schicht 2''' befasst sich mit den baulichen Gegebenheiten.

'''Schicht''' 3 mit den einzelnen IT-Systemen. Server, Clients.

'''Schicht 4''' betrachtet die Vernetzung der Systeme inklusive Netz- und Systemmanagement wie auch Firewall.

'''Schicht 5''' beschäftigt sich mit den eigentlichen Anwendungen (E-Mail, Webserver, Faxserver, Datenbanken)

Ein System kann mehreren Bausteinen zugeordnet sein. Beispiel Mailsever unter NT: PC unter Windows NT, servergestütztes Netz, Peer-to-Peer-Netz, Windows NT Netz und Mail.

=== 6.2 Sicherheitsprozess ===

Um die IT-Sicherheit zu etablieren muss ein Prozess in Betrieb genommen werden. Dazu braucht es Verantwortliche die sich diesem Thema annehmen, verfolgen und laufend verbessern.

*Initialisierung des Prozesses
*Gefährdungsanalyse
*Leitlinien
*'''IT-Strukturanalyse'''
*'''Schutzbedarfsfestellung'''
*'''Modellierung'''
*'''Ergänzende Sicherheitsanalyse'''
*'''Basis Sicherheitscheck'''
*Realisierungsplan
*Realisierung
*Sicherstellung im Betrieb (Monitoring) und dann zurück zu "Gefährdungsanalyse"

(fett = Sicherheitskonzept)

=== 6.3 Definition der Verantwortlichkeiten ===

Bevor ein Sicherheitsprozess etabliert werden kann braucht es eine verantwortliche Person (IT Sicherheitsbeauftragter). Dieser

* ist verantwortlich für die ganze IT-Sicherheit
* koordiniert die Erstellung des IT Sicherheitskonzeptes, Notfallkonzeptes, etc.
* erstellt den Realisierungsplan der Sicherheitsmassnahmen
* prüft die Realisierung und
* stellt den Informationsfluss zur Leitungsebene und zu den einzelnen IT Verantwortlichen sicher.

=== 6.4 Gefährdungsanalyse und Leitlinien ===

Jedes Unternehmen muss in einer Sicherheitsleitlinie (Policy) definieren wieviel ihr "IT-Sicherheit" bedeutet. Dies hängt unter andrem vom Vertraulichkeitsgrad der zu verarbeitenden Daten ab. Für kritische Datensammlungen schreibt der Gesetzgeber spezielle Sicherheitsmassnahmen vor.

Der Inhalt besteht aus:
*Stellenwert der IT-Sicherheit
*Sicherheitsziele und Strategie
*Zusicherung der Unternehmensleitung, dass die Policy durchgesetzt wird
*Beschreibung der verantwortlichen Organisation

=== 6.5 Erstellung des Sicherheitskonzeptes ===

Das Sicherheitskonzept beschreibt die Summe aller Massnahmen die ergriffen werden müssen um die Sicherheit zu gewährleisten.

Vorgehen:

#'''IT-Strukturanalyse'''. Auflistung aller Komponenten. Bilden von Gruppen.
#'''Schutzbedarfsfestellung'''. Für jede Applikation definieren wie wichtig sie für den Fortgang des Geschäftsprozesses ist. Dadurch wird der benötigte Schutz definiert. Die Applikation definiert dadurch auch wie die darunter liegenden Komponenten (Server, Netz) zu schützen sind.
#'''Modellierung'''. Die Komponenten werden den Bausteinen aus dem Grundschutzhandbuch gegenübergestellt und die Massnahmen festgehalten (Modellieren).
#'''Sicherheitsanalyse'''. Entspricht einer Risikoanalyse. Komponenten mit einem hohen Schutzbedarf müssen einer separaten Analyse unterworfen werden. Grund: Der Grundschutz definiert nur eine mittlerer Sicherheit.
#'''Basis Sicherheitscheck'''. Die entstanden Modellierung wird als Prüfplan benutzt um herauszufinden welche Massnahme bereits umgesetzt ist bzw. noch umgesetzt werden muss. Das Resultat ist der "Realisierungsplan".
#'''Realisierungsplan'''. Gleiche Tätigkeiten zusammenfassen. Der It-Sicherheitsprozess wacht über die Umsetzung und Einhaltung der Massnahmen.

Das Ergebnis des '''Basis Sicherheitscheck''' dient als Kommunikationsmittel zur Unternehmensleitung stellt das Sicherheitskonzept dar.

=== 6.6 Umsetzung ===

Aus dem Sicherheitskonzept geht auf Grund des Realisierungsplanes hervor welche Massnahmen noch umgesetzt werden müssen.

Damit das Konzept kein Konzept bleibt müssen '''sämtliche''' Mitarbeiter für dieses Thema sensibilisiert werden. Man nennt diesen Prozess "Security Awareness".

=== 6.7 Aufrechterhaltung im laufenden Betrieb ===

Der Sicherheitsprozess muss laufend kontrolliert und auch aktualisiert werden (inkl. Sicherheitskonzept). Auch die Reaktionen auf neue Ereignisse müssen geregelt werden.

Der Grundschutz besteht aus zwei wichtigen Komponenten:

*'''Der Sicherheitsprozess'''. Dieser beinhaltet die Erarbeitung, Umsetzung und Kontrolle von nötigen Sicherheitsmassnahmen.
*'''Das Sicherheitskonzept'''. Stellt die Summer aller Massnahmen dar um die Sicherheitsziele zu erreichen.

== 7 Strukturanalyse ==

Die Strukturanalyse steht am Anfang jedes Projektes und ist in folgende Schritte gegliedert:

*'''Netzplanerhebung:''' Erstellen einer grafischen Übersicht aller Komponenten
*'''Gruppenbildung:''' Zusammenfassen gleicher Komponenten
*'''Erhebung Komponenten''': Ableiten der relevanten Komponenten
*'''Erhebung Applikationen:''' Erfassen aller geschäftsrelevanten Applikationen
*'''Erhebung Systeme pro Applikation:''' Übersicht welche Komponenten für welche Applikation nötig sind

=== 7.1 Netzplanerhebung ===

Ein Netzplan stellt alle sicherheitsrelevanten IT Komponenten in einer grafischen Übersicht dar. Typische Komponenten:

*Clients, Server, Netzkomponenten, Netzdrucker
*Netzverbindungen, LAN, WAN
*Verbindungen des betrachteten Bereiches nach aussen

Zu jeder Komponenten gehören folgende Information (auf die Übersicht oder auf separater Liste)

*eindeutige Bezeichnung (z.B. Hostname oder eine Identifikationsnummer)
*Typ und Funktion (z.B. Webserver für ISPRM)
*Die zugrunde liegende Plattform (Hardware und Betriebssystem sprich I386 / Windows Server 2003)
*Standort
*Zuständiger Administrator
*Art der Netzanbindung und Netzadresse

Auch die Verbindungen zwischen den Komponenten müssen dokumentiert sein:

*Art der Verbindung (Kupfer, Glas, Ethernet)
*maximale Datenübertragungsrate (z.B. 1Gbps)
*verwendende Protokolle (Ethernet, TCP/IP)
*Details zum externen Netz

Informationen müssen laufend aktualisiert werden. Das bedeutet, dass Managementunterstützung benötigt ist.

=== 7.2 Komplexitätsreduktion durch Gruppenbildung ===

Gleiche Komponenten werden zu Gruppen zusammengefasst wenn alle Komponenten...

*vom gleichen Typ sind
*gleich oder nahezu gleich konfiguriert sind
*gleich oder nahezu gleich ins Netz eingebunden sind
*den gleichen Rahmenbedingungen unterliegen und
*die gleichen Anwendungen bedienen

'''Wichtigstes Beispiel''': Die Clients

=== 7.3 Erhebung der Infrastrukturkomponenten ===

Der nächste Schritt ist die Erstellung einer Liste in Tabellenform welcher vom Netzplan abgeleitet ist.

Die Liste enthält folgende Spalten

{| border="1"
! Nr. !! Beschreibung !! Plattform !! Anz. !! Ort !! Status !! Anwender / Administrator
|-
| S1 || Fileserver || 2K3 || 3 || Zofingen || installed || IT333
|-
| S2 || AD || 2K8 || 2 || Zofingen || installed || IT333
|-
| C1 || Clients IT333 || 2K6 || 7 || Luzern || installed || IT333
|}

=== 7.4 Erfassen der Anwendungen ===

Erfassen der unternehmenswichtigen Applikationen. In der Regel nur folgende:

*Anwendungen deren Daten den höchsten Bedarf an Vertraulichkeit besitzen
*Anwendungen deren Daten den höchsten Bedarf an Korrektheit (Integrität)besitzen
*Anwendungen welche die kürzeste tolerierbare Ausfallzeiten haben

Beispiel:

{| border="1"
! Anwendungsnummer !! Anwendung!! personenbezogene Daten
|-
| A1 || Persy || X
|-
| A2 || Benutzer-Authentisierung || X
|-
| A3 || ISPRM ||
|}

=== 7.4 Erfassen der Komponenten pro Applikation ===

Nun wird beschrieben welche Applikation auf welchem Server läuft. Diese Übersicht könnte wir folgt aussehen

{| border="1"
! Anwendungsnummer !! Anwendung!! personenbezogene Daten || S1 || S2 || S3 || S4
|-
| A1 || Persy || X || X || || X ||
|-
| A3 || ISPRM || || || || || X
|}

Diese Informationen sind späte für die Schutzbedarfserhebung nötig. Wird z.B. eine Applikation als "hoher Schutzbedarf" bezeichnet, so benötigen die darunter liegenden Systeme automatisch das gleiche Mass an Schutz.

Die Strukturanalyse gibt am Schluss Auskunft darüber

*welche Komponenten vorhanden sind
*welche Applikationen im Einsatz sind und
*welche Applikationen welche Komponenten benötigen oder benutzen

== 8 Schutzbedarfsfeststellung ==

Der Schutzbedarf beschreibt das Mass an Sicherheit, das für eine Komponente nötig ist. Daran lassen sich die Sicherheitsanforderungen der übrigen Komponenten bestimmen.

Die Schutzbedarfsfeststellung orientiert sich an folgendem Modell der IT Architektur

*Organisation
*Daten
*Applikation
*System und Betriebssystem
*Netzwerke
*Infrastruktur

Die Schutzbedarfsfeststellung erfolgt in vier Schritten:

#Definition der Schutzbedarfskategorien
#Definition der Schadensszenarien auf IT Anwendungen (prüfen der Auswirkung bei Verlust von Verfügbarkeit, Vertraulichkeit oder Integrität)
#Anschliessend wird daraus der Schutzbedarf der einzelnen Komponente abgeleitet
#Aus dieser Ergebnissen wird abschliessend der Schutzbedarf der Übertragungsstrecken und der Räume definiert.

=== 8.1 Definition Schutzbedarfskategorien ===

Da der Schutzbedarf oft nicht quantifizierbar ist, muss man sich in der Regel auf qualitative Aussagen verlassen

Schutzbedarfskategorien:
*'''Niedrig bis Mittel''': Schaden ist begrenzt und überschaubar
*'''Hoch''': Schaden kann beträchtlich sein
*'''Sehr hoch''': Schaden kann existenzbedrohend oder katastrophal sein

=== 8.2 Schutzbedarfsfeststellung für Anwendungen ===

Um zu definieren welche Verletzbarkeit eine Anwendung aufweist, wird die Frage "Was wäre wenn ...?" gestellt. Erinnerung: Eine Verletzbarkeit stellt beim Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit einen Schaden dar.

Für jede Applikation aus der Strukturanalyse wird pro Grundwert (Vertraulichkeit, Integrität, Verfügbarkeit) der Schutzbedarf (niedrig, mittel, hoch, sehr hoch) inkl. einer Begründung aufgelistet.

=== 8.3 Schutzbedarfsfeststellung für IT Systeme ===

Aus der Strukturanalyse ist bekannt welche Applikation welche Systeme nutzt. Das gleiche Mass an Schutz wie die Applikation benötigen auch die darunter liegenden Systeme.

Wenn mehrere Applikation auf einem Server betrieben werden werden die Sicherheitsanforderungen der Applikation mit dem höchsten Schutzbedarf angewendet.

=== 8.4 Schutzbedarfsfeststellung für Kommunikationsverbindungen ===

Die Kommunikationsverbindungen sind genau so wichtig wie die Systeme selbst. Es nützt nichts aufwändige Schutzmassnahmen vorzunehmen wenn im Gegenzug Daten unverschlüsselt übers Netz gehen.

Folgende Betrachtungsweise dient zur Identifikation der kritischen Verbindungen

*Verbindungen bei welchen es sich um Aussenverbindungen handelt bzw. Verbindungen dir über öffentlichen bzw. unsicheren Grund gehen.
*Verbindungen mit schutzbedürftigen Informationen
*Zentrale Verbindungen (Hauptverbindungen). Der Ausfall einer solchen kann die gesamte Informatik beeinträchtigen.

Pro Verbindungen werden dabei folgende Informationen in eine Schlusstabelle eingetragen:

*Die Verbindungsstrecke (von, nach)
*ob es sich um eine Aussenverbindung handelt
*ob der Schutzbedarf aus der Vertraulichkeit, Integrität oder der Verfügbarkeit resultiert.

=== 8.5 Schutzbedarfsfeststellung für Räume ===

Die Räume in denen sich die Komponenten benötigen ebenfalls eine Schutz. die Höhe des Schutzes leitest sich logischerweise von den darin enthaltenen Komponenten ab.

In den meisten Unternehmen gibt es ein Zonenkonzept, in dem System mit gleichen oder ähnlichen Schutzbedürfnissen zusammen betrieben werden.

=== 8.6 Interpretation der Ergebnisse ===

Der IT-Grundschutz versteht sich als "mittlerer bis hoher" Schutz. Komponenten mit einem hohen Schutzbedarf müssen genauer untersucht werden.

Der Schutzbedarf wird wie folgt ermittelt:

#Schutzbedarfskategorien definieren
#Schadensszenarien für Anwendungen definieren und Applikationen betreffend Integrität, Vertraulichkeit und Verfügbarkeit bewerten.
#Schutzbedarf der einzelnen Komponenten ableiten
#Schutzbedarf der Übertragungsstrecken und der Räume ableiten.

== 9 Grundschutz-Modellierung und Basis Sicherheitscheck ==

Im nächsten Schritt werden die nötigen Sicherheitsmassnahmen bestimmt. Die geschieht indem die Komponenten den Bausteinen aus dem Grundschutzhandbuch gegenübergestellt werden.

Weiter wird geprüft welche Massnahmen schon realisiert wurden

=== 9.1 Grundschutz-Modellierung ===

bei der Grundschutz-Modellierung wird jeder Baustein aus dem IT-Grundschutz einzeln betrachtet und entschieden wann er für welche Komponenten angewendet werden kann.

[[image:BspSicherheitskonzept.jpg|Beispiel Sicherheitskonzept]]

Abschliessend muss die Vollständigkeit überprüft werden indem auf Grund des Netzplanes alle Komponenten durchgegangen wird.

=== 9.2 Sicherheitsanalyse ===

Bei der Sicherheitsanalyse werden Komponenten mit hohem bis sehr hohem Schutzbedarf separat analysiert. Das Vorgehen ist gleich wie bei der Risikoanalyse. Das Ergebnis der Sicherheitsanalyse sind besondere Bedrohungen und besondere Massnahmen. Diese werden als separater Baustein in das Grundschutzhandbuch bzw. in das Sicherheitskonzept eingefügt.

[[Image:BspErweiterungSchichtenmodell.jpg]]

=== 9.3 Basis Sicherheitscheck ===

Auf Grund der Modellierung sind pro Komponente die Massnahmen bekannt. Einige Massnahmen sind evtl. bereits umgesetzt, andere nicht. Um herauszufinden was noch umgesetzt werden muss, wird ein Basis-Sicherheitscheck durchgeführt.

Der Ist-Zustand wird mit dem Sollzustand verglichen. Die Abweichungen werden in einem Realisierungsplan festgehalten.

Um den Stand der empfohlenen Massnahmen festzuhalten, werden folgende Kategorien herbeigezogen:

{| border="1"
! Kategorie !! Bedeutung
|-
| Entbehrlich || Die Umsetzung ist nicht notwendig, weil wereits eine andere gleichwertige Massnahme im Einsatz ist
|-
| Ja || Die empfohlene Massnahme ist bereits vollständig umgesetzt
|-
| Teilweise || Die empfohlene Massnahme ist (noch) nicht vollstaändig oder wirksam umgesetzt
|-
| Nein || Die empfohlene Massnahme ist kaum oder gar nicht umgesetzt
|}

Beispiel Realisierungsplan:

[[Image:BspRealisierungsplan.jpg|Beispiel Realisierungsplan]]

Der Realisierungsplan wird dem Management vorgelegt. Dort wird über die Umsetzung entschieden und die Termine un Verantwortlichkeiten werden definiert und schriftlich festgehalten.

== 10 Internet-Dienste ==

=== 10.1 WWW ===

Festlegung der Sicherheitsstrategie:

*Wer darf welche Informationen publizieren?
*Welche Dateien dürfen auf Grund ihres Inhaltes nicht auf dem Webserver publiziert werden? (z.B. vetrauliche Daten)
*Welche Zugriffsbeschränkungen sollen auf den WWW-Server realisiert werden? (Wer darf auf welche Infos zugreifen)

Sicherheitsstrategie für die WWW-Nutzung:

*Wer erhält WWW Zugang?
*Die Browser müssen so konfiguriert werden, dass sie das grösste Mass an Sicherheit garantieren.
*Auf dem Firewall (proxy) können white-lists bzw. black-lists konfiguriert werden um Zugriff auf rechtlich bedenkliche Seiten zu verhindern.
*Nach dem Download von Dateien müssen diese explizit auf Viren geprüft werden.

Sicherer Betrieb eines WWW-Servers:

*Webserver muss auf minimalem Betriebssystem installiert sein (unnötige Dienste deaktivieren)
*Die Kommunikation sollte durch einen Paketfilter auf ein Minimum beschränkt werden.
*Die Administration des Webservers sollte nur über eine sichere Verbindung erfolgen
*Konfigurationstype: Auflisten von Verzeichnisinhalt unterbinden, "symbolische Links" deaktivieren.

Schutz der WWW-Dateien

*Files auf dem Webserver sind üblicherweise statisch und können deshalb einfach und automatisiert auf Veränderungen geprüft werden.

Schutz vor unbefugtem Zugriff

*über IP-Adresse
*Benutzername Passwort
*Zertifikat

Sicherheit von WWW-Browsern

*vom Web heruntergeladen Dateien dürfen nicht automatisch starten (sie können z.B. Makrovieren enthalten)
*kein automatische Installieren von Plug-Ins denen man nicht vertraut

Cookies

bei Bedarf kann das Anlegen von Cookies komplett unterbunden werden.

Datensammlungen

Ein schlecht konfigurierter Proxy-server kann massive Datenschutzverletzungen nach sich ziehen.

Ein Grossteil der Massnahmen liegt im Verantwortungsbereich des Benutzers. Es müssen deshalb entsprechende Weisungen erstellt UND kommuniziert werden.

=== 10.2 E-Mail ===

Sicherheitspolitik festlegen:

* Wer erhält Mail Zugriff?
* Welche Informationen dürfen versendet werden?
* Wie verbindlich ist ein E-Mail?

Folgende Punkte sind zu beachten:

*E-Mailprogramme müssen so konfiguriert sein, dass maximale Sicherheit erreicht wird. Der Benutzer darf diese Einstellungen nicht ändern.
*Daten dürfen erst übermittelt werden, sich der Benutzer identifiziert und authentifiziert hat.
*Signaturen verwenden
*Mailversand wird oft protokolliert. dabei sind die Datenschutzbestimmungen zu beachten.

Regeln für die Benutzer festlegen:

*Beim Mailversand an mehrere Benutzer BCC verwenden.
*"Betreff" immer ausfüllen
*Ein- und ausgehende Mails müssen immer auf Viren überprüft werden.

Mailadressen, Verteilerlisten:

*Namenskonvention von Mailadressen festlegen
*Verteilerlisten regelmässig auf Aktualität prüfen

Namenskonventionen haben den Nachteil, dass sie für Spammer einfacher zu erraten sind.

Schutz vor Attacken

Achtung vor...
*Mailbomben
*Archiven mit EXE oder ähnlich

Massnahmen gegen Spam:

*Filter auf dem Mailserver
*Weisungen betreffend Publikation der eigene Mailadresse (z.B. in Newsgroups)

Sicherer Betrieb eines Mail-Systems

*lokale Mails müssen im internen Netz bleiben
*nur der Eigentümer darf Zugriff auf die Mailbox haben
*eingehende Mails müssen auf der Firewall oder auf dem Firewall nach schädlichen Inhalten durchsucht werden
*Über Filterregeln muss es möglich sein ausgehende oder hereinkommende Mails zu filtern
*Mailserver darf nicht als Mailrelay benutzbar sein
*Die Mailprogramme der Benutzer müssen für maximale Sicherheit konfiguriert sein. Weiter müssen die Benutzer darauf hingewiesen werden, dass sie die Konfiguration nicht ändern dürfen.

== 11 Mobile Zugriffsdienste ==

Bei mobilem Zugriff erfolgt dieser fast immer über öffentliche Leitungen. Deshalb muss dieser Zugang besonders geschützt werden.

=== 11.1 Firewall ===

Arten von Firewalls

*Paket-Filter: Auf den unteren OSI-Schichten werden nach speziellen Regeln Pakete weitergeleitet oder abgefangen.
*Application-Gateway: Dieser schaut zusätzlich in die Pakte hinein und untersucht die Nutzdaten. Dies setzt aber voraus, dass der Application-Gateway die Applikation kennt.

Voraussetzungen:

*Jede Kommunikation zwischen den beiden Netzen muss ausnahmslos über die Firewall geführt werden.
*Auf dem Firewall darf nichts anderes laufen (minimales Betriebssystem)
*Die Administration des Firewall erfolgt über einen gesicherten Weg
*Die Firewall erlaubt nur festgelegte Verbindungen anhand IP-Adresse, Dienst, Richtung, Zeit und Benutzer

Die Firewall bietet keinen umfassenden Schutz:

*Filterung von aktiven Inhalten (Applets, ActiveX) ist nur zum Teilk möglich
*Über eine bestehende Verbindung kann ein Tunnel aufgebaut werden in welchem sich beliebige andere Protokoll tunneln lassen
*Firewalls schützen nicht vor DoS Attacken.
*Ein Firewall schützt nur vor Angriffen von aussen und nicht vor Angriffen von innen.

Sicherheitspolitik

*Welche Informationen und Dienste dürfen durch die Firewall (beide Richtungen)
*Welche Information soll die Firewall verstecken (z.B. die interne Struktur oder den Benutzernamen)
*Welche Authentisierung soll verwendet werden
*Welcher Datendurchsatz ist zu erwarten

Folgende organisatorische Regeln sind ebenso erforderlich:

*Festlegen welche Informationen protokolliert werden
*Die Benutzer müssen über ihre rechte informiert werden (Nutzdaten-Filterung)
*Angriffe müssen nicht nur verhindert, sondern auch erkannt werden.
*es ist zu klären welche Aktionen bei einem Angriff gestartet werden

Filterregeln

*Alles was nicht explizit erlaubt ist, ist verboten
*Alle Rechner des internen Netzes müssen berücksichtigt werden
*Welche Dienste stehen zu welcher Zeit zur Verfügung

Firewall Architektur

*Dual-homed Gateway Ein Application-Gateway mit zwei Interfaces welche die beiden Netze verbindet.
*Screened Gateway: Hier wird zusätzlich zum Application Gateway ein paketfilter benutzt. Der Paketfilter befindet sich entweder vor oder nach oder vor und nach dem Application Gateway. z.B. (Internet -> Paket-Filter -> Application Gateway -> Paket Filter -> internes Netz)

Sichere Anordnung weiterer Komponenten

Neben dem LAN gibt es noch weitere Komponenten welche speziell geschützt werden müssen und für welche speziell Regeln gelten (Ein Mail-Server muss z.B. aus dem Internet erreichbar sein)

[[Image:BspDMZ.jpg|Beispiel DMZ mit Mail, Web, und DNS Server]]

== 11.2 Kryptopgraphie ==

Symmetrische Verschlüsselung

Empfänger und Absender besitzen den selben Schlüssel mit welchem man ver- und entschlüsseln kann. Das verfahren ist sehr schnell und bietet eine gute Sicherheit. Das Problem ist der Austausch des Schlüssels: Wenn ein Dritter den Schlüssel mitlesen kann, kann er in die Kommunikation eingreifen und diese manipulieren.

Asymmetrische Verschlüsselung

Empfänger und Absender haben unterschiedliche Schlüssel welche aber (mathematisch) zusammengehören. Mit Schlüssel A verschlüsselte Nachrichten können nur mit Schlüssel B entschlüsselt werden und umgekehrt.

Einer der beiden Schlüssel kann als "private Key" und der andere als "public Key" verwendet werden.

[[Image:BspAsymKey.jpg]]

Die asymmetrische Verschlüsselung ist etwa 1000 mal langsamer als die symmetrische Verschlüsselung. Deshalb wird oft ein kombiniertes Verfahren benutzt. Eine Verbindung wird asymmetrisch begonnen und ein "Sitzungsschlüssel" (symetrisch) ausgemacht und ausgetauscht. Danach wird die verbindung symetrisch mit dem geheimen Key verschlüsselt.

Authentifikation

Wie kann ein ein Empfänger sicher sein, dass eine Nachricht wirklich vom angegeben Absender stammt? bei der Authentifikation wird ebenfalls eine asymmetrische Verschlüsselung angewendet.
Schlüssel B ist bekannt (public). Der Absender verschlüsselt Nachricht mit (privatem)Schlüssel A. Wenn Empfänger mit Schlüssel B die Nachricht entschlüsseln kann ist klar, dass die Nachricht mit Schlüssel A verschlüsselt wurde. Nur der gewünschte Absender hat Schlüssel A.

[[Image:BspAuth.jpg]]

Elektronische Unterschrift

Um eine Nachricht elektronisch zu unterschreiben wird über die Nachricht ein Hash berechnet. Der Hash wird mit Schlüssel A verschlüsselt. Empfänger entschlüsselt den Hash mit Schlüssel B und bildet ebenfalls einen Hash über die Nachricht. wenn beide Hash identisch sind, ist klar, dass die Nachricht nicht verändert wurde.

Zertifikate

Mit Hilfe von Zertifizierungsstellen könne öffentliche Schlüssel verteilt werden. Die öffentlichen Schlüssel dieser Zertifizierungsstellen sind in den Browsern bereits installiert.

=== 11.3 Remote Access ===

Sicherheitsrichtlinie:

*Welcher Benutzer darf auf welche Daten, Applikationen, Dienste zugreifen.
*Welcher Benutzer darf sich zu welchen Zeiten mit welchem RAS Zugang verbinden.
*Welche Authentisierungsmechanismen sind für den Zugriff zu benutzen?
*Welche Zugriffsrechte werden vergeben?
*Ist der schreibende Zugang auf Daten erlaubt? (oder evtl. nur auf bestimmtes Verzeichnis)
*Wie werden Authentisierunsgfehler behandelt?
*Wie ist der technische und organisatorische Ablauf um ein gesperrtes RAS-Konto wieder zu aktivieren?
*Kann auch aus der Ferne ein Konto entsperrt werden? Ablauf?
*Welche Daten werden protokolliert?

Weil RAS Verbindungen immer über ungesicherte Verbindungen wie Modem oder Internet gehen, muss eine starke Verschlüsselung eingesetzt werden. Die gängigste Variante ist das Tunneling (VPN)

=== 11.4 Telearbeit ===

bei der Telearbeit gelten generell die selben Sicherheitsmassnahmen. Zusätzlich muss die Handhabung folgender Punkte definiert sein:

*Datensicherung
*Verschlüsselung der Daten
*Aktentransport (vom Büro nach Hause und umgekehrt)
*Zugriffsrechte
*Umgang mit Datenträgern

== Gesamtzusammenfassung ==

Der IT-Grundschutz ist eine Methode um schnell und relativ einfach ein mittleres bis hohes Mass an Schutz in einer IT-Infrastruktur aufzubauen.

Die Ausgangslage ist Verletzbarkeit bezüglich den vier Grundbedrohungen:

*Verfügbarkeit
*Vertraulichkeit
*Integrität
*Verbindlichkeit

Trifft nun eine reale Bedrohung auf eine solche Verletzbarkeit, spricht man von einem Risiko.
Das Risiko lässt sich in einem Geldbetrag ausdrücken und beziffert den finanziellen Verlust, der ein Unternehmen bei dessen Eintritt hinnehmen muss. Um dies zu verhindern, wird ein Sicherheitsprozess etabliert, der diese Risiken aufdecken und minimieren soll.
Neben den organisatorischen Massnahmen ist die Erarbeitung eines Sicherheitskonzepts die entscheidende Arbeit. Das Sicherheitskonzept beschreibt die Summe aller Massnahmen, die ergriffen werden müssen, und wie gross der Aufwand ist, um die Sicherheitsziele umzusetzen.
In einer Modellierungsphase werden Bausteine aus dem IT Grundschutz der vorhandenen Infrastruktur gegenübergestellt und die nötigen Massnahmen abgeleitet. Dort wo Bausteine fehlen, müssen sie mit einer Sicherheitsanalyse erarbeitet werden. Einzelne Bausteine
können auch miteinander verschmolzen werden, um die Übersicht zu erhöhen. Ein Baustein wird beschrieben, indem die Bedrohungen, die auf ihn wirken, und die Massnahmen, die ergriffen werden müssen, aufgezeigt werden. Bedrohungen werden eingeteilt in:

*höhere Gewalt,
*menschliche Fehlhandlungen,
*technisches Versagen,
*vorsätzliche Handlungen und
*organisatorische Mängel,

während Massnahmen den Bereichen

*Infrastruktur,
*Personal,
*Organisation,
*Hardware und Software,
*Kommunikation und
*Notfallvorsorge

zugeordnet werden.

Der Sicherheits-Basischeck nimmt nun alle relevanten Massnahmen pro Komponenten auf und untersucht, ob diese schon umgesetzt sind. Das Resultat ist ein Realisierungsplan, welcher der Leitung zur Genehmigung vorgelegt wird.
Periodisch wird der ganze Prozess wieder durchlaufen, um sicherzustellen, dass alle Änderungen in der Infrastruktur, neue Bedrohungsbilder und Massnahmen eingeflossen sind.

Das folgende Beispiel soll nochmals den Ablauf eines IT-Grundschutzprozesses praxisnah aufzeigen.

In den Wagen von Herrn Meier, Mitarbeiter einer autonomen Versicherungsagentur, wird eingebrochen. Sein Arbeitsnotebook wird dabei glücklicherweise übersehen, da dieses unter den Beifahrersitz gerutscht ist. Gleichwohl fragt er sich im Nachhinein, was passiert wäre, wenn das Notebook mitgenommen worden wäre. Immerhin befinden sich höchst vertrauliche Kundendaten darauf (Lebensversicherungsinformationen und entsprechende Krankheitsfälle. Er beschliesst dies mit dem Leiter der Agentur, Herrn Koller, zu diskutieren. Herr Koller ist über den Vorfall ebenso beunruhigt und beschliesst den Sicherheitsmassnahmen auf den Grund
zu gehen. Die entsprechende «Managementunterstützung» wurde etabliert. Zunächst überlegt sich Herr Koller, wie wohl die generelle Situation innerhalb der Agentur ist. Er kommt zum Schluss, dass auf allen IT-Systemen vertrauliche Kundeninformationen liegen und generell seine Agentur einer «hohen bis sehr hohen» Gefährdung ausgesetzt ist. Er führt also eine «Gefährdungsanalyse» durch.
Diese Erkenntnis setzt er in eine Weisung (Security Policy) um und versendet ein Memo an alle Mitarbeiter, in
dem er darauf aufmerksam macht. dass «Alle Kundendaten besonders geschützt werden müssen». In der nächsten Woche setzt sich Herr Koller mit dem IT-Lieferant zusammen und sie erarbeiten zusammen das IT-Sicherheitskonzept. Sie versuchen zu definieren, welche IT-Mittel in der Agentur im Einsatz sind. Dies sind sechs PCs, vier Notebook~, ein LAN-Server, ein Switch, ein Router und ein RAS-Server. Beide haben eine einfache «Strukturanalysy» durchgeführt.
Nun definieren sie den «Schutzbedarf», indem sie sich überlegen, wo welche Daten im Einsatz sind. Sie kommen zum Schluss, dass

*PC-Systeme einen mittleren Schutzbedarf haben, da sie nur in der Agentur stehen,
*Notebooks einen hohen Schutzbedarf haben, da sie einen Teil der Kundendaten enthalten, und
*der RAS- und LAN-Server einen sehr hohen Schutzbedarf haben.

Alle übrigen Komponenten haben einen geringen Schutzbedarf und werden nicht betrachtet.
Im nächsten Schritt «modellieren» sie diese Umgebung gemäss IT-Grundschutz, indem sie das IT-Grundschutzhandbuch aufschlagen und die PC, Notebooks und Server einer der bereits beschriebenen Komponenten gegenüberstellen.
Sie finden:

*«Notebooks» entsprechen zum Beispiel «Tragbarer PC» und «PC unter Windows NT».
*«LAN-Server» entspricht «Servergestütztes Netz» und «Windows NT Netz» etc.

Sie notieren sich die vorgeschlagenen Massnahmen aus dem IT-Grundschutzhandbuch. Danach notieren sie sich, welche Massnahmen bereits umgesetzt sind und welche noch offen stehen. Sie machen einen «Basis-Sicherheitscheck». Am Schluss steht ein Realisierungsplan, den der Lieferant mit der Angabe ergänzt. wie viel Aufwand (in Franken) die Realisierung pro Massnahme kosten wird. Dem IT-Lieferant wird nun eine Zeit gewährt. in der die noch nicht realisierten Massnahmen einzubauen (zu realisieren) sind.

Zwei Monate später kontrolliert der IT-Lieferant die definierten Massnahmen und entdeckt, dass der Mitarbeiter Herr Huber bereits sein Power-On-Passwort aus dem Notebook wieder entfernt hat. Herr Koller unterstreicht in der nächsten Mitarbeitersitzung die Sicherheitsrichtlinien und betont. dass diese einzuhalten sind. Herr Koller hat den «Betrieb» des IT-Grundschutzes sichergestellt.
Ein Jahr später setzt sich Herr Koller wieder mit dem IT-Lieferanten zusammen und sie beginnen wieder die zu diesem Zeitpunkt im Einsatz stehenden Systeme aufzunehmen, einen Basis-Sicherheitscheck, eine Modellierung etc. durchzuarbeiten. Herr Koller hat den «Grundschutzprozess» geschlossen und eine periodische Überprüfung initialisiert.

Informatiker FA M222 Zusammenfassung

2019-08-01T13:08:27Z

Christian:

= OO-Grundlagen =

== Was heisst modellgetriebene Architektur (MDA) ==

MDA ist eines der grossen Themen bei OMG (www.omg.org). Das Ziel von OMG ist es , mittels MDA die Geschäftslogik von der darunter liegenden Technik zu entkoppeln

*Systeme sollen klug durchdacht werden
*System in Modellen darlegen
*Jedes Modell adressiert eine bestimmte Thematik und die Modelle bauen aufeinander auf.
*Im Idealfall kann das ganze System als Modell beschrieben und dann mit einem Generator erstellst werden.
*'''Wichtiger Anspruch''': Modell muss durch Mensch und Maschine gelesen werden können.

MDA Modellebenen:
*M3: Metadatenebene
*M2: Beschreibung der Sprache oder Notation
*M1: Hier modelliert der Entwickler
*M0: Ebene der Laufzeitinstanzen

Um die einzelnen Modelle als XMI speichern zu können, entwickelte die OMG die XMI. XMI = gemeinsames Format für Import- und Export unterschiedlicher Tools.

'''Modelltransformationskette:'''

[[Image:Modelltransformationskette.gif]]

*'''CIM-Modell''' (Computational Independent Modell): enthält vor allem die fachlichen Anforderungen (unabhängig von der Technik)
*'''PIM''' (Plattform Independent Modell): bildet vor allem das Analysemodell unabhängig von der zukünftigen Plattform
*'''PSI''' (Platform Specific Implementation): repräsentiert den eigentlichen Code
*'''PM''' (Platform Model) beschreiben die Quell- und Zielplattform als Metamodelle und die dazugehörenden Transformationsregeln. Damit z.B. eine Klasse aus dem Fachklassenmodell eine Tabelle im physischen Datenmodell ergibt.

Eine Transformation von Modellen bzw. Code-Generierung heisst '''Forward-Engineering'''. Wenn aus dem Code ein Design-Modell erstellt wird, heisst dies '''Reverse-Engineering'''.

== Welches sind die Grundelemente von OO? ==

=== Das Objekt ===

*Ein Objekt ist immer einmalig und hat somit eine klare Identität. (auf Programmebene eindeutig durch die Speicheradresse identifiziert)
*Ein bestimmtest laufendes Exemplar eines Objektes entspricht einer Instanz
*Objekte haben Eigenschaften (Attribute), Methoden (Funktionen)
*können auf Ereignisse (Events) reagieren.
*Objekte können Nachrichten austauschen

[[Image:222-1.gif]]

*Zugriffsmöglichkeiten sind klar geregelt
*Alle sichtbaren (public) Methoden bilden die '''Schnittstelle''' gegenüber der Umwelt
*Das Verbergen der inneren Funktionsweise wird '''Kapselung''' (Encapsulation) genannt.

Ein Objekt hat eine definierte Lebensdauer (Life-Cycle):
*Geburt: Kreieren (Instantiieren, Create) eines Objektes
*Leben: eine aktive Instanz
*Tod: zerstören (Destroy) des Objektes

=== Die Klasse ===

*Die Verallgemeinerung wird '''Klasse''' genannt.
*Im Modell wird eine Generalisierung der gleichartigen Objekte vorgenommen, womit die Klassen entstehen

[[Image:222-3.gif]]

*Klassen wiesen untereinander Beziehungen auf.
*Die Beziehungen werden Assoziation genannt und beschreiben den Kardinalität (Multiplizität) zwischen der Menge der Objekte

Im folgenden Beispiel hat eine Firma mindestens einen Mitarbeiter, kann aber auch beliebig viele haben.

[[Image:222-4.gif]]

'''Umgekehrte Richtung''': Ausgehend von der Oberklasse vererben sich die Eigenschaften und Methoden auf die Unterklasse. Dabei handelt es sich um eine '''Spezialisierung''', da die Unterklasse eine immer speziellere Ausprägung ausweist.

[[Image:222-5.gif]]

*Klassen welche nicht mehr weiter generalisiert sind, werden Basisklasse, Wurzelklasse oder RootClass genannt.
*übergeordnete Klassen werden Oberklasse (Superclass) oder Vaterklasse genannt.
*Spezialisierte Klassen sind Unterklassen oder Sohnklassen (Childclass)

Klassen bei denen keine Instantiierung von Objekten erlaubt sind, sind abstrakte Klassen.

'''Binding''':
*Statisches Binding: Der methodenaufruf ist fix programmiert und bei der Kompilierung bekannt.
*Spätes Binding: Die Methodenaufrufe werden nach dem Kompilieren aber vor der Laufzeit bekannt.
*Dynamisches Binding: Die Methodenaufrufe werden erst bei der Laufzeit zugeordnet.

Beim Polymorphismus ist der Methodenaufruf erst während der Laufzeit bekannt:

[[Image:222-6.gif]]

Bei der Mehrfachvererbung vererbt eine Klasse Eigenschaften aus zwei oder mehreren Klassen (wird nicht von allen Sprachen unterstützt). Werden nur die Signatur (Schnittstelle) vererbt, so implementieren die Entwickler über Interface-Klassen.

Klassen, deren Instanzen nicht Objekte sonder wieder Klassen sind, werden Metaklassen genannt. Der Einsatz von Metaklassen ist eher in der Entwicklung eines Frameworks anzusiedeln und braucht einen hohen Grad an Abstraktionsvermögen der teilnehmenden Entwickler.

== Wie sieht ein typisches OO-Vorgehen aus? ==

Projektvorgehensmodelle helfen, das Risiko eines Projekt-Crashes zu minimieren. Sie bilden Teile der konstruktiven Qualitätssicherungsmassnahmen, damit Fehler vermieden werden und Projektziele nicht aus den Augen zu verlieren:

'''Projekt-Zieldreieck: Termine, Kosten, Qualität'''

[[Image:222-7.gif]]

Projekte werden in Phasen abgewickelt. Die meisten Phasenmodelle bestehen aus folgenden Phasen:

*Vorstudie: Projektumschreibung, ist das Projekt sinnvoll
*Fachkonzept: Anforderungen aufnehmen und fachliche Spezifikation, was soll mit dem Projekt abgedeckt werden.
*DV-Konzept (Datenverarbeitungskonzept): EDV-technischer Entwurf, wie wird das System gebaut.
*Realisierung: Programmierung, Beschreibung,m eigentlicher Bau des Systems
*Einführung: Schulung, Installation, Going Live

Aus diversen Gründen hat sich jedoch ein Vorgehen in kleinen überblickbaren Schritten bewäjhrt. Daraus entstanden die folgenden Modelle:

*Spiralmodell
*Ration Unified Process (IBM)
*oose Engineering Process (OEP)
*Extreme Programming (XP)

XP ist ein Vertreter der agilen Softwareentwicklung. Diese beinhaltet folgend vier Thesen um Software, schnell, flexibel und wendig zu entwickeln:

*Personen und deren Interaktionen gehen Prozessdefinitionen und Werkzeugen vor
*Gut funktionierende Software nützt mehr als ausgedehnte Dokumentation
*Enge fachliche Zusammenarbeit mit dem Kunden bringt das Projekt weiter als ausgedehnte Vertragsverhandlungen
*Auf Änderungen reagieren ist wichtiger als den ursprünglichen Plan einzuhalten

=== Prinzipen des OO-Vorgehens ===

*'''OO-Projekte werden iterativ in überschaubaren Inkrementen entwickelt'''.
*'''OO-Projekte werden von der Benutzeranforderung her getrieben'''.
*'''OO-Projekte werden architekturzentriert und modellbasiert entwickelt'''. (Weil der zugrunde liegende Geschäftsprozess vermutlich länger lebt als die verwendete IT-Technologie muss die Lösung Technologie unabhängig entwickelt werden.)

=== Phasen - Meilensteine ===
Aus dem natürlichen Ablauf eines Projektes ergeben sich vier Hauptphasen:

*'''1.Phase: Einstieg (Inception'''). Hier geht es darum den Fachbereich zu verstehen. Der Geschäftsprozess wird beleuchtet und eventuell einem Business Process Reengineering unterzogen. Der Anwender legt die wichtigsten Anforderungen und Einschränkungen dar. Eine erste Architekturskizze zeigt mögliche Realisierungswege auf. Das gesamte Projekt wird geplant und die Kosten-Nutzen Überlegungen dienen als Basis für den Go-Nogo Entscheid.

*'''2. Phase: Ausarbeitung (Elaboration)'''. Die Detail werden weiter ausgearbeitet. Die Anforderungen sollte vollständig vorhanden sein. Der Schwerpunkt liegt im Analyse/Design-Prozess, in welchem die Architektur, der gesamte Entwurf und ein Prototyp entsteht.

*'''3. Phase: Konstruktion (Construction)'''. Das System wird gebaut. die Komponenten werden entwickelt und integriert. Ziel ist ein lauffähiges und getestetes System.

4. Phase: Überleitung: (Transition). Das fertige System wird in dir Produktivumgebung gebracht. Dies beinhaltet die Schulung, Installation und weiter Anpassungs- und Testarbeiten.

=== Iteration (Wiederholung) ===

In jeder Phase sind eine bis mehrere Iterationen zu planen. Eine Iteration ergibt als Resultat einen definierten geprüften Zustand.

=== Prozesse - Tätigkeiten ===

Die einzelnen Prozesse beschreiben je Phase und Iteration welche Tätigkeiten ausgeführt werden und welche Resultate (Artefakte) erwartet werden.

Unified Prozess:

[[Image:222-8.gif]]

In den einzelnen Disziplinen sind die Module des Fachausweises zu erkennen: Geschäftsmodellierung, Anforderungen definieren, Analyse und Entwurf, Realisierung, Test + QS, Einführung, Projektmanagement, Change- und Configmanagement.

=== Artefakte - Lieferobjekte ===

Die Resultate werden ja nach Vorgehensmodell unterschiedlich benannt. Der Begriff Artefakt zeigt auf den gegensatdn (das eigentliche Resultat) hin. Während Lieferobjekt eher auf die Verantwortung appelliert, was zu liefern ist. Ein Artefakt kann sowohl ein Dokument als auch eine lauffähige Komponente sein.

=== Rollen - Projektmitarbeiter ===

Die wichtigsten Rollen in einem Softwareentwicklungsprojekt:

[[Image:222-9.gif]]

=== Zeitschätzungsverfahren ===

Zuerst muss man sich ein Bild über die nachfolgend aufgeführten '''Einflussfaktoren''' machen:

*Innovationsgrad des Projektes und deren zugrunde liegenden Techniken
*Qualität, Vollständigkeit und Klarheit der Aufgabenstellung
*Qualität, Motivation und Grösse des Projektteams
*Quantität der zur Verfügung stehenden Ressourcen
*Projektorganisation (Führungsstil, Kompetenten, Informationswege)
*Handhabung des Change Managements
*Komplexität der Schnittstellen bzw. Systemintegration
*...

Die wichtigste Komponenten ist die Erfahrung mit dem Teams selbst. Wer für ein neu zusammengestelltes Team eine Zeitschätzung abgeben muss, soll immer auf den grossen Unsicherheitsfaktor hinweisen. Unabhängig von einer bestimmten Technik ist der Schätzvorgang ein iterativer Prozess, welcher während der ganzen Projektdauer für die noch ausstehende Tätigkeiten eine periodische Überprüfung und Korrektur benötigt.

== Wie ist die Unified Modelling Laguage (UML) aufgebaut? ==

Die "Three Amigos" entwickelten in den neunziger Jahren ein gemeinsame Modellierungssprache welche nun von der OMG als Standard weiter gepflegt wird.

Das Hauptziel der UML ist es, eine einfache und für alle Beteiligten verständliche Modellierungssprache anzubieten. UML deckt vie Grundbedürfnisse der Systementwicklung ab:

*Visualisierung
*Spezifizieren
*Dokumentieren
*Programmieren (mittels bidirektionalen Konvertern können Klassencode erstellt oder aus bestehendem Programmcode wieder Diagramme erstellt werden.)

=== UML-Werkzeuge ===

=== Architektur-Sichten ===

[[Image:222-10.gif]]

=== UML Sprachelemente ===

Folgender Aufbau ist in den Metadefinitionen festgelegt:

*Struktur (statische Aspekte)
**Klassen mit dem Klassendiagramm, Paketdiagramm und Objektdiagramm
**Komponenten mit dem Komponentendiagramm
**Kompositionsstruktur mit dem Kompositionsstrukturdiagramm und Kollaborationsdiagramm
**Physische Verteilung von Artefakten mit dem Verteildiagramm
*Verhalten (dynamische Aspekte)
**Aktivität, Aktion mit dem Aktivitätendiagramm
**Interaktion mit den Integrationsdiagrammen
**Zustandsautomat mit dem Zustandsdiagramm
**Anwendungsfall mit dem Anwendungsfalldiagramm
*Erweiterung durch eigene Profile
**Erweiterung des Metamodells durch spezielle eigene Elementgruppen wir z.B. J2EE-Profile, MS .NET mit Web-Services und COM Profile.
*OCL - Object Constraint Language

= Artefakte im Analyseprozess =

*Die Analyse nimmt die Informationen aus den beiden vorangegangenen Prozessen der Geschäftsmodellierung und der Anforderungsaufnahmen
*Daraus wird die Beschreibung erstellt WAS im neuen System gelöst werden soll.

Dies bedingt eine Teamarbeit folgender Personen:
*Systemanalytiker
*Domänenexperten (Anwenden)
*Evtl. berate für Spezialgebiete (z.B. Datenschutz)
*Prototypenentwickler

Dadurch entsteht eine Systembeschreibung welche nach und nach komplettiert wird.

== Was beinhaltet die Systembeschreibung? ==

*Ausgangssituattion (Auslöser, Umfeld, Organisation)
*aktuelle Schwachstellen
*Zielsetzungen der neuen Lösung
*Beschreibung der Aufbau-Organisation
*Abriss des aktuellen Systems und dessen Integration (ergibt Rückschlüsse über die Schnittstellen)
*zu berücksichtigende gesetzliche Regelungen
*Projket-Begriffsverzeichnis

== Welche Modelle werden während der Analyse erstellt? ==

Die Modellierung verfolgt mehrere Zwecke:
*eindeutige Kommunikation zwischen den Beteiligten
*grafische Visualisierung von komplexen Zusammenhängen
*Möglichkeiten geben, Modelle auf Vollständigkeit, Konsistenz und Machbarkeit hin zu prüfen.

'''Modelle''':
*Das '''Anwendungsfalldiagramm''' basiert auf der IST-Situation der Business-Prozesse und den Anforderungen an das System. Hier wird die Frage beantwortet wie das System genutzt wird.
*Im '''Basismodell''' spürt der Analyst die Objekte auf. Aus den Objekten entstehen Klassen inkl. ersten Eigenschaften und Methoden. Das Basismodell ist Voraussetzung für das statische Analysemodell.
*Im '''statischen Analysemodell''' werden die Basismodell gefunden Element in Beziehung gesetzt. Weiter werden Generalisierungen vorgenommen (Klassen zu Oberklassen)
*Im '''dynamischen Analysemodell'''l werden die Interaktionen der Element dargestellt (zeitliche Ablauffolgen und Abhängigkeiten, mögliche Parallelität, Synchronisation von Aktivitäten, sowie Austausch von Nachrichten.

== Wie sieht das Prototyping in der Analysephase aus? ==

*Der Anwender wird beim Erstellen der Analyseprototyp einbezogen
*Dieses '''partizipative Protoptyping''' hat den Vorteil, dass grundlegenden Fehlüberlegungen in den Maskenabläufen und den wichtigsten Inhalten schon sehr früh ausgemerzt werden können.
*Für die Entwicklung können spezielle Autorentools oder Entwicklungsumgebungen eingesetzt werden (z.B. Rapid Application Development Tools)
*Die Maskendetail interessieren in dieser Phase noch nicht. Deshalb wird von einem '''Low-Fidelity-Wegwerf-Prototyp''' gesprochen.
*Meistens werden unterschiedliche Varianten erstellt um die beste Variante zu finden.

= Anwendungsfallmodell =
*Das Anwendungsfallmodell ist eine Black-Box-Betrachtung
*Aus jedem Geschäftsprozess werden die Geschäftsfälle (Business cases) identifiziert. Diese lassen sich in Geschäftsanwendungsfällen beschreiben und enthalten die Stereotyp-Bezeichnung "business".
*Der Analytiker trägt die jeweiligen Anwendungsfälle zusammen und vervollständigt sie mit dem Domänenexperten.

Die Anforderungen lasse sich in 3 Gruppen einteilen:
*Rahmenbedingungen (Projektumfeld, verfügbare Infrastruktur, Firmenstandards, gesetzliche Vorgaben)
*nicht-funktionale Anforderungen (Perfomanz, Benutzerfreundlichkeit, Robustheit, Wartbarkeit, ..)
*funktionale Anforderungen (was soll das System leisten)

== Wie werden Anwendungsfälle erstellt? ==

'''1. Schritt: Informationen vervollständigen.'''
*Mit Domänenexperten, dem Management, den Kunden, Lieferanten Prozess-Owner und anderen Wissensträgern werden die Details durchgegangen.

'''2. Schritt: potenzielle Akteure finden.'''
*Welches sind die Kunden im betreffenden Geschäftsprozess?
*Welche internen Stellen sind beteiligt?
*zu welchen internen Stellen finden ein Datenaustausch statt?
*zu welchen externen Stellen finden ein Datenaustausch statt?

Die gefunden Akteure können in einem nächsten Teilschritt zu gleichen Gruppen zusammengefasst und einheitliche Namen gegeben werden.

z.B. beim Seminarhotel
*Kunden
*Mitarbeiter
*externe IT-Systeme
*interne IT-Systeme

'''3.Schritt: Anwendungsfälle identifizieren'''
*Ein Anwendungsfall besteht aus einer Folge zu Aktivitäten welche durch ein bestimmtest Ereignis ausgelöst wird.
*Meistens ist ein Akteur beteiligt für welchen mindestens ein sichtbares Ergebnis entsteht.
*Ein Anwendungsfall kann also durch ein auslösendes Ereignis und ein erhaltenes Resultat identifiziert werden.

'''4. Schritt: Akteure und Anwendungsfälle verbinden.'''
*Hier erfolgt ein erster Entwurf des Anwendungsfalldiagramms. Ausgehend von den definierten Anwendungsfällen wird der auslösende Akteure verbunden. So entsteht die Grundlage um an den Anwendungsfällen weiter zu arbeiten (im Normalfall CASE-Tool unterstützt).

'''5. Schritt: Akteure und Anwendungsfälle beschreiben und komplettieren'''

Es wird eine Beschreibung mit folgenden Eigenschaften und Inhalten erstellt:
*muss von allen Beteiligten verstanden werden (also nicht EDV-technisch verfasst)
*Akteure
*Vor/Nachbedingungen
*Ergebnisse
*Ablauf
*immer aus Sicht des Geschäftstreibenden beschreiben
*auf logische Abfolge der Anwendungsfälle achten

'''6. Schritt. Beziehungen zwischen Anwendungsfällen modellieren'''
*gleichartige Aktivitätsabfolgen suchen
*wenn vorhanden, dann als einen eigenen Anwendungsfall herausnehmen und in den anderen Anwendungsfällen mit einer "include"-Beziehung verwenden.

'''7. Schritt. Sicht überprüfen'''
*interagiert jeder Use Case unmittelbar oder mittelbar mit mindestens einem Akteur?
*Enthält kein Diagramm mehr als 10 Use Cases?
*Sind die Namen intuitiv verständlich?
*Ist die Beschreibung für Anwender verständlich?
*Sind die Begriffe konsistent?
*Sind die Use Cases weder zu mächtig noch zu klein?
*Ist die Beschreibung des Ablaufs nicht zu detailliert?
*Ist die Anwendung und nicht ein Dialogablauf beschrieben?
*sind alle Aspekte abgedeckt?
*Gibt es kein Widersprüche?

== Wie werden Anwendungsfalldiagramme erstellt? ==

*Ein entsprechend angeschriebenes Rechteck repräsentiert das zukünftige '''Informationssystem'''.
*Die Anwendungsfälle sind innerhalb des Systems zu platzieren.
*'''Akteure''' sind ausserhalb des Systems
*Die Anwendungsfälle werden mit einer durchgezogenen Linie mit den Akteuren verbunden. Die Linien nennt man '''Assoziationen'''.
*Die Akteure sind mit der in dieser Situation relevanten Rolle angeschrieben.
*Die Anwendungsfälle sollten mit einer prägnanten Bezeichnung versehen sein (Substantiv und Verb wie z.B. Reservation durchführen)

[[Image:222-11.gif]]

[[Image:Anwendungsfalldiagramm.gif]]

*Akteure können Personen, OE oder andere fimeninterne oder firmenextern Informationssystem sein.
*Neben Strichmännchen dürfen auch andere Stereotypen verwendet werden.
*für ein anderes System hat sich das Knoten-Symbol der Verteildiagramms durchgesetzt.

'''Assoziationen:'''
*eine einfache Assoziation bedeutet eine bidirektionale Kommunikation zwischen dem Akteur und dem System (durchgezogene Linie ohne Pfeil)
*ist die Navigierbarkeit nur auf einen Seite gegeben, so wird dies mit einem offenen Pfeil und einem Kreuz am anderen Ende angedeutet (siehe Beispiel Rechnung an Kunde).
*Vor- bzw. Nachbedingungen werden mit einer gestrichelten Linie und offenem Pfeil gezeichnet. Siehe Beispiel: Check-Out nur möglich wenn Check-In durchgeführt wurde.
*Spezielle Anwendungsfälle können generalisiert werden. Alle Beziehungen des generellen Anwendungsfalles gelten dann automatisch für den speziellen. Die Beziehung wird durchgezogener und geschlossenem, gefüllten Pfeil gezeichnet. Siehe Beispiel "Reservation vornehmen" "Seminarreservation vornehmen".
*Gleiche Abläufe dürfen in separate Anwendungsfälle ausgelagert werden. Mit der Stereotype-Bezeichnung "include" können diese hinzugefügt werden. Dadurch werden Redundanzen vermieden. das Modell wird übersichtlicher und besser wartbar.
*"extend" ist ähnlich wie "include". Es kann aber eine Bedingung angegeben werden welche dann an einem "extension point" andockt.

[[Image:222-12.gif]]

[[Image:Include-extend.png]]

== Wie werden Anwendungsfälle beschrieben? ==

*Die Beschreibung soll möglichst kurz und prägnant sein.
*für alle Beteiligten verständlich
*Aus Sicht der Geschäftstreibenden

Die einzelnen Teile der Beschreibung:
*Name
*Spezialisierung von
*Kurzbeschreibung
*Akteure
*Auslöser
*Vorbedingung
*Eingehende Information
*Ergebnisse
*Nachbedingungen
*Ablauf
*Kategorie (Primär = notwendiges, häufiges Verhalten / Sekundär = notwendiges, seltenes Verhalten / Optional: nicht notwendiges Verhalten)

== Vom Anwendungsfall zum Testfall ==

Es ist sinnvoll bereits in dieser Phase die Testfälle und die Akzeptanzkriterien zu beschreiben. Diese können direkt aus den Anwendungsfällen abgeleitet werden.

= Statisches Analysemodell =

*Die Anwendnungfsfälle und das Pflichtenheft bilden den Input zum statischen Analysemodell.
*Dieses konzentriert sich auf die Sichtweise des Aufbaus und die Struktur des Systems.
*Objekte bzw. Klassen mit ihren Attributen sind zu identifizieren
*Ebenso die Beziehungen zwischen den Klassen.
*Der Analytiker stellt die Resultate in einem UML-Klassendiagramm dar

== Welchem Zweck dienen CRC-Karten (Class - Responsibility - Collaborator)? ==

Auf den CRC-Karten werden in Arbeitssitzungen die Informationen gesammelt und auf einer Pin-Wand in der richtigen Beziehung platziert. Die erhaltenen Infos fliessen in die eigentliche Modellierung ein.

[[Image:222-13.gif]]

*Unter "Responsibility" werden die Verantwortlichkeiten eingetragen.
*Collaborator" spricht die Beziehungen zu den anderen Klassen an.

Durch Beantworten folgender Fragen ergeben sich die ersten Klassen:

*Mit welchen Personen arbeitet das System zusammen?
*Welche Dinge sind im Geschäftsprozess involviert oder beschrieben?
*Welche Artikel bzw. Leistungen werden dem Kunden geliefert?
*Welche Papiere, Dokumente werden erstellt?
*Welche Informationen fliessen in das System?

Die Beziehungen:
*Welche fachlichen Beziehungen bestehen zwischen den Objekten?
*wie viele Objekte einer Klasse sind an einer Beziehung beteiligt?

== Wie werden Pakete geformt? ==

Ein Namensraum ist ein paketierbares Modellelement welches andere Element enthält. Pakete können ganz unterschiedlich Elemente enthalten. Pakete helfen Ordnung in die Anwendungen zu bringen. Gleichartige Artefakte lassen sich so bequem in ein entsprechendes Pakte versorgen. Man kann Elemente auch anderen Paketen wieder zugänglich machen.

Vier unterschiedliche Festlegungen der Sichtbarkeit:
*public: (+) für alle sichtbar
*private: (-) nur für die eigene Klasse sichtbar
*protected: (#) nur für die eigene Klassen und die Unterklassen sichtbar.
*package: (~) nur innerhalb des gleichen Paketes sichtbar

Pakete können andere Pakete importieren. Dazu gibt es folgende beiden Möglichkeiten:
*"import": die Elemente des anderen paketes werden importiert. Wenn das importierende Pakete von einem anderen Paket importiert wird, werden auch die von diesem Paket importierten Pakete ebenfalls impoirtiert.
*"acccess": Damit greift man nur auf die Elemente zu, ohne diese weiter zu exportieren.

Beide werden als Abhängigkeit gezeichnet, das heißt in der Form einer gestrichelten Linie mit einer offenen Pfeilspitze. Zu beachten ist, dass das importierte Paket am Ende mit der Pfeilspitze gezeichnet wird.

[[Image:222-14.gif]]

== Wie sieht ein Analyseklassenmodell aus? ==

Die Klassen mit den wichtigsten Attributen, den Assoziationen mit deren Multiplizität (Kardinalität) sowie den Verebungsstrukturen werden identifiziert.

=== Klasse ===

*Bezeichnung soll eine natürliche Identifikation ermöglichen
*eindeutige Bezeichnung im ganzen Modell
*keine Leerzeichen im Namen oder andere Sonderzeichen (ausser _)
*Zusammengesetzte Namen sollten mit GrossKlein-Schreibung abgegrenzt werden.
*diese Regeln gelten auch für Pakete, Attributs und Operationsbezeichnungen

Namen von abstrakten Klassen werden kursiv geschrieben. In Handzeichnung sollte aber besser den Constraint {abstract} angegeben werden.

In UML wird die Klasse als Rechteck gezeichnet:

[[Image:222-15.gif]]

=== Attribute ===

*bilden die Eigenschaften einer Klasse
*Name soll möglichst selbsterklärend sein.
*jedes Attribut weist einen Attributswert je Instanz auf
*Klassenattribute weisen hingegen einen Attributswert für die gesamte Menge der Objekte auf. Diese sind unterstrichen.
*Ein von anderen Attributswerten abgeleitetes Attribut beginnt mit einem Slash. Für das Design werden diese Attribute meist gestrichen, da sie sich errechnen lassen.

[[Image:222-16.gif]]

*Jedes Attribut weist eine Sichtbarkeit aus
*der Typ des Attributes zeigt die Art der darin enthaltenen Daten auf. Primitiver Datentyp (string, int), Aufzählungsdatentyp (Enum), Komplexer Datentyp (Objekt)

Beispiel Aufzählungsdatentyp:

[[Image:222-17.gif]]

*Im Design stehen die Typen der jeweiligen Plattform zur Verfügung (Java, .NET, ...)
*Attribute können bei den Instantiierung einen Initalwert erhalten. Dazu wird mit einem Gleichheitszeichen der Wert zugewiesen. Ohnen diese Anaben enthalten die Attribate den Leerwer (Null-Value)
*Attribute welche nur gelesen werden dürfen, haben das Merkmal {readonly}

Bei Attributen welche mehrere Werte enthalten können, wird die Multiplizität in eckigen Klammen angegeben. Die Listen können wir folgt beschrieben bzw. eingeschränkt werden:

*{bag}: beliebige Liste von Werten
*{unique}: jeder Attributswert darf nur einmal vorkommen.
*{ordered}: die Liste der Werte ist sortiert.

Künstliche Schlüsselattribute dürfen in der Analyse noch nicht festgelegt werden. Dies ist Design-Arbeit. Auch Fremd-Schlüsse sind noch nicht festzulegen.

Durch die Assoziation wurd die Navigierbvarkeit sichergestellt.

Die Syntax der Attributsdefinition lautet:

'''[sichtbarkeit][/][:typ[multiplizität][=initialwert][{eigenschaftswert}]'''

=== Operationen ===
*Erst während der Erstellen des dynamischen Analysemodells vervollständigt der Analytiker die Operationen mit den dazu gehörenden Parametern.
*Der Namen und die Parameter bilden die Signatur
*Die Menge aller Operationen bilden das Verhalten der Klasse
*Operationen enthalten die selben Sichtbarkeitshinweise wie die Attribute.

Die Paramter sind in der Klammer mit Komma abgetrennt. Ohne spezielle Angaben sind dies Eingabeparameter. Ansonsten:

*in: Eingabewert (Default)
*out: Rückgabewert
*inout: beides

Den Parametern ist der Typ (mit Doppelpunkt) beizufügen.

Zusicherungen welche das System beim Aufruf bzw. beim Abschluss der Operation einhalten muss, werden mit OCL in geschweiften Klammern (Constraints) angegeben:

*Vorbedingung: {pre: KundenNr ist gültig}
*Invariante (Zusicherung während Ausführung): {inv: Objekt ist für Dritte gesperrt}
*Nachbedingung: {post: Änderung ist persistiert)

Sofern eine Operation einen Typ besitzt, entspricht dies dem Typ des Rückgabeparameter.

Je nach Verantwortlichkeit der Aufgabe welche die Operation hat, werden folgenden Arten unterschieden:

*Konstruktor
*Destruktor
*Setter
*Getter
*Link (Aufbauen Objektbeziehung)
*Unlink
*Getlink
*Query (Dateninhalt abfragen. Mit/ohne Berechnung)
*Update (speichern, persititieren)

Die Syntax der Operation lautet:

'''[sichtbarkeit] name (parameterliste) [:typ] {constraints}'''

=== Assoziationen (Beziehungen) ===

*zeigen die Beziehungen zwischen Klassen auf
*werden mit einer ausgezogenen einfachen Linie dargestellt
*im Analyseklassendiagramm sind diese zu benennen.
*Wenn die Leserichtung nicht von oben nach unten oder nicht von links nach rechts geht, muss diese mit einem kleinen ausgefüllten Pfeil angegeben werden.
*Am Ende der Assoziation besteht die Möglichkeit die Rolle anzugeben welche dies entsprechende Klasse in dieser Beziehung hat.

Die Multiplizität definiert die gültige Kardinalität.

Beispiel:

*Eine Firma ist Kunde des Seminarhotels
*Die Firma führt ein Seminar durch an welchem 3 Mitarbeiter teilnehmen.
*Die Kardinalität ist in diesem Fall 3
*Da wir keine Begrenzung der Anzahl vorgeben, ist die Multiplizität 1..*.

Gültige Multiplizitäten sind in positiven ganzzahligen Werten anzugeben. Ein Von-bis-Wert ist mit zwei Punkten ".." anzugeben. Sobald der Wert 0 möglich ist, ist diese Beziehung optional.

Beispiele:

*1
*0..1
*1..3, 7
*1..*
*0..* ist gleichbedeutend wie *

'''Beispiel:'''

[[Image:222-18.gif]]

kann wie folgt gelesen werden:

*Ein Kunde besteht aus mindestens einer Person, kann aber aus beliebig vielen Personen bestehen.
*Genau eine Person ist die Kontaktperson beim Kunden.

Ein '''Objektdiagramm''' zeigt konkrete '''Instanzen''' mit deren Beziehungen aus. Es hilft konkrete Situationen darzustellen. Das obige Beispiel sieht als Objektdiagramm z.B. wie folgt aus:

[[Image:222-19.gif]]

'''Navigierbarkeit:'''
*werden mit einem offenen Pfeil bzw. dem Kreuz modelliert.
*wenn nichts angegeben ist, ist sie bidirektional.
*Die Navigierbarkeit muss im Design bei unidirektionalen (nur ein Weg) explizit modelliert werden. Entsprechend werden die dazu notwendigen Link-Operationen gebildet.

Wie im Beispiel angegeben, macht es keinen Sinn, vom Hotelzimmer her zu wissen wer dies präferenziert.

[[Image:222-20.gif]]

Wenn ein Objekt eine Beziehung zu einem Objekt der gleichen Klasse hat, spricht man von einer '''reflexiven Assoziation'''. Im folgenden Beispiel können Personen Mitarbeiter oder Vorgesetzte sein. Jeder Mitarbeiter hat genau einen Vorgesetzten und jeder Vorgesetzte hat 1 bis 10 "Untergebene".

[[Image:Reflexive-Assoziation.gif]]

'''noch ein Beispiel:'''

[[Image:222-21.gif]]

*Wenn man eine 1:1-Beziehung hast, muss dies überprüft werden.
*Wenn die eine Klasse nur eine Ergänzung bildet, müssen diese in der Analysephase zu einer Klasse zusammengefasst werden.
*Nur wenn eine separate Objektidentität vorhanden ist, darf eine 1:1-.Beziehung angewendet werden. Beispiel: Klasse Ehemannen und Ehefrau.

'''Aggregation:'''
*Ein Stockwerk besteht aus diversen Räumen.
*Die Räume sind Teil des Stockwerkes.

Eine solche Beziehung wird mit UML in einer '''Aggregation'''. Am Assoziationsende ist beim Ganzen ein nicht ausgefüllter Rhombus. Die Aggregation wird in der Analysephase gerne angewendet, im Design jedoch weggelassen, da eine Implementierung nicht stattfindet.

[[Image:222-22.gif]]

anderes Beispiel: Restaurant und Stuhl. Stuhl kann auch ohne Restaurant leben.

'''Komposition''':
*wenn die einzelnen teile nicht ohne die Existenz des Ganzen leben können, handelt es sich um eine Komposition.
*wird mit einem gefüllten Rhombus dargestellt.
*hat im Gegensatz zur Aggregation einen direkten Einfluss auf das Design.
*es muss sichergestellt sein, dass beim Löschen des Ganzen auch die dazugehörenden teile gelöscht werden, bzw. dass während der Existenz des Teiles das dazu gehörende Objekt des Ganzen auch vorhanden ist.

[[Image:222-23.gif]]

'''Zusicherungen:'''

Zwischen Assoziationen kann es Abhängigkeiten geben. Diese werden mittels Zusicherungen (Constraints) modelliert. Beide Beziehungen werden mit einer gestrichelten Linie verbunden und die Zusicherung in Klammern geschrieben:

*OCL Ausdruck
*or: keine, nur eine oder beide Beziehungen dürfen vorhanden sein.
*xor: es darf nur eine Beziehung vorhanden sein.
*and: es müssen beide Beziehungen vorhanden sein.

[[Image:222-24.gif]]

'''Assoziationsklasse:'''
*Es kommt vor, dass Bezeihungen ebenfalls Attribute und Operationen haben.
*Damit werden diese Assoziationen zu Assoziationsklassen.
*Im Analyseklassenmodell wird dies mit einer Klasse, welche eine gestrichelte Linie zur Assoziation aufweist, dargestellt.
*jede konkrete Beziehung bildet somit ein Objekt mit den entsprechenden Attributswerten.
*Für das Design-Modell muss dieses Konstrukt jedoch in 2 Beziehungen und einer normalen Klasse aufgelöst werden.

[[Image:222-25.gif]]

anderes Beispiel:

[[Image:Assoziationsklasse.gif]]

=== Generalisierung ===

*schon in anderen Kapiteln erwähnt.
*UML-Notation: ein geschlossener Pfeil der zur Oberklasse zeigt.

'''Beispiel eines Analyseklassediagramms:'''

[[Image:222-27.gif]]

=== Verwendung von visuellen Stereotypen ===

[[Image:222-26.gif]]

=== Wie präzisieren wir ein Modell mit OCL ===

*Visuelle Modelle haben grenzen
*z.B. wenn man modellieren will, dass nur Personen des gleichen Kunden in das gleiche Hotelzimmer bewohnen sollen.

Mit OCL lassen sich Modelle mit Einschränkungen und Präzisierungen ergänzen. OCL ist eine seiteneffektfreie Sprache. Es können keine Werte geändert werden. ähnlich SQL "select". In Bezug auf MDA bietet OCL die Voraussetzung, damit ein Modell vollständig und eindeutig auf einer hohen Abstraktionsebene definiert werden kann.

OCL-Befehle weisen immer einen '''Kontext''' auf, der eine Zuordnung auf ein konkretes Modellelement enthält:

*Classifier (wie z.B. Klasse, Akteur, ...)
*Feature eines Classifiers wie Attribut oder Operation.

'''Beispiele''':

Festlegen, dass die verantwortliche Person mindestens 18 Jahre alt sein muss:

''context: Kunde

inv: self.Kontaktperson.Alter >= 18''

"inv" steht für Invariant, was mit einer "immer zutreffenden Zusicherung" übersetzt werden kann.

=== Prüfung des Modells ===

Folgende Fragen helfen bei der Überprüfung des statischen Analysemodells um die Qualität zu steigern

*Sind die Namen aussagekräftig (Klasse, Attribute, Operationen)?
*korrektes Abstraktionsniveau
*es dürfen keine Reports, Benutzeroberflächen oder Implementierungsdetails als Klassen modelliert sein.
*sind die nötigen Rollen spezifiziert?
*Liegen unberechtigte 1:1 Beziehungen vor?
*etc...

== Wie helfen Analysemuster Lösungen zu finden? ==

Für immer wieder auftauchende Problemstellungen wurden Musterkataloge geschaffen.

Beispiele:

[[Image:222-28.gif]]

[[Image:222-29.gif]]

= Dynamisches Analysemodell =

*Die Dynamik des System wird beschrieben.
*wird auch '''Interaktionsmodell''' genannt (weil dargestellt wird wie die Objekte interagieren)
*Der Schwerpunkt liegt auf de Innensicht (White Box). Im Gegensatz zum Anwendungsfallmodell (Black-Box-Betrachtung)

== Wie werden Prozessabläufe als Aktivitätendiagramm modelliert? ==
*Sobald ein Anwendungsfall einige Bedingungen und Nebenläufigkeiten hat, ist eine verbale Beschreibung nicht mehr geeignet.
*Stattdessen kommt das Aktivitätendiagramm zum Zug (grafische Darstellung)
*Das Aktivitätendiagramm kann auch für die Beschreibung des gesamten Geschäftsprozess verwendet werden(z.B. anstelle vom BPMN)

'''Beispiel eines einfachen Aktivitätendiagramm:'''

[[Image:222-30.gif]]

(Aktivität = ganzes / Aktion = Teilschritt bzw. kleinste ausführbare Einheit)
*genau ein Startknoten
*ein oder mehrere Endknoten
*Jede Aktion muss ein Ausgang haben.
*Bedingung bei Entscheidungsknoten muss gemäss UML-Regel in eckigen Klammern stehen)
*Alternativ kann Bedingung in einer Notiz angegeben werden.

'''Beispiel parallele Kontrollflüsse:'''

[[Image:222-31.gif]]

*Splitting- bzw. Synchronisationsbalken dürfen auch waagrecht sein
*erst wenn alle Zweige beim Synchronisationsbalken ankommen, läuft der Prozess weiter.
*Ausnahme: paralleler Kontrollfluss kann beendet werden.

'''Objekte / Pins / Buffers'''

*In UML 2.0 steht neu die Möglichkeit der Modellierung eines Objektflusses zur Verfügung. Objekte welches als Parameter übergeben werden oder Aktionen welche Objekte erzeugen werden als Pin visualisiert.
*Der "centralBuffer" bildet eine Zwischenspeicher für Objekte.
*Der "datastore" ist die Endablage von Objekten.

Im folgenden Beispiel werden auch Konnektoren gezeigt:

[[Image:222-32.gif]]

'''Ereignisse''':

Im folgenden Beispiel sind folgende Ereignisse zu sehen
*normales Ereignis, d.h. ein Signal aus einem Ereignis empfangen
*Zeitereignis
*Ausnahmeereignis
*Ein Ereignis auslösen, d.h. ein Signal senden

[[Image:222-33.gif]]

'''Aktivitätsbereiche''':
*Mit Aktivitätsbereichen kann dargestellt werden wer für eine Aktion verantwortlich ist.
*Diese dürfen horizontal oder vertikal angebracht werden.
*Nicht mehr als Aktivitätsbereiche verwenden.
*Alternativ können die Aktivitätsbereiche mit Klammern angegeben werden.

[[Image:222-34.gif]]

'''Dekompositionen'''
*Wenn sich hinter einer Aktion ein komplexer Ablauf verbirgt, kann dies mit einem gabelähnlichen Symbol unten rechts angezeigt werden.
*Diese Aktion ist dann ein Aufruf zu einer eigenständigen Aktivität
*So können Dekompositionen auf unterschiedlichen Ebenen modelliert werden

[[Image:222-35.gif]]

'''Strukturelemente'''
*Für den Einsatz in der Designphase stehen auch Strukturelemente von Selektionen und Iterationen zur Verfügung

[[Image:222-36.gif]]

File:MartinOdell.png

2019-08-01T13:06:42Z