KIS- Konzeption von Informationssystemen

Wenn ein Entwurf zeigt, dass die SW mehrere Aufgaben gleichzeitig durchführen muss, kommt dier nebenläufigkeit ins SPiel. Je nach unterlegtem Betriebssystem wird hier von Multitasking und Multireading gesprochen.

Kommunikation und Synchronisierung über Standardkomponenten des Betriebssystem

Ein Prozess ist die Abbildung einer Aufgabe in SW > vom Betriebssystem erzeugt, endet wenn die Funktion beendet wird.

Je mehr Aufgaben aktiv sind, desto komplexer wird das Zusammenspiel der beteiligten Komponenten.

Kommunikation zwischen den Prozessoren erhöt die Komplexität der SW

Entscheid, welche Aufgaben zu welchen Zeitpunkten zu erfüllen sind. Zuordnungen:

> Module bestimmten Prozessen zuordnen

> Prozesse zu Prozessoren zuordnen

> Daten Speicherbereichen zuordnen

> Kommunikationskanäle festlegen

(Abschätzung bezüglich des Verbrauchs der belegten Resourcen)

Bei vielen Anwendungen gilt es, systemweit bestimmte Konsistenzen zu erzeugen. Solche Konsistenzen werden als Systemaspekte bezeichnet und müssen im Konzept berückisichtigt werden. Eine konsistente benutzerfürhung bei allen Komponenten kann ein solcher Aspekt sein

Folgende Fragen sind zu beachten:

> Können mittels Standardsoftware oder Komponetenzukauf Kosten gespart werden?

> Kann die Einbettung in ein Framework Vorteile bringen?

> Sind Bibliotheken sinnvoll zu verwenden?

> Können bewährte Architektu- oder SW-Muster verwendet werden?

> Kann das Konzept so angepasst werden, dass vorhandene SW benutzt werden kann?

Die Aspekte:

> Effektivität: die Anforderungen des Auftraggebers erfüllen

> Wirtschaftlichkeit: tauglich, kostengünstig, wiederverwertbar

> SW-technische Qualität: leicht verständlich, robust, zuverlässig, änderungsfreundlich, performant

Ein guter Entwurf ist oft auch elegant. Er hat klare Strukturen und löst die Aufgabenstellung durch die einfachstmögliche Weise. man kann dies auch subjektiv als Schön bezeichnen.

> Abgrenzung: Gliederung in einzelne Schritte

> Prozesse: Analyse, Modellierung, Varianten, Zukauf, Dokumentation, Prüfung

> Architektur: Funktionsorientierte Architektur, Objektoreintierte Architektur, Prozessoreintierte Architketur, Komponentenoreintierte Architektur, Wiederverwendung (Design Patterns, Frameworks)

Die Kostenschätzung für Software ist ein komplexes und teilweise politisch zu betrachtendes Thema:

> Preisreduktion bis zum Minimum, danach Schrittweise Steigerung, bis zur Überschreitung

> Hauptkomponenten werden abgeschätzt (Fehlerbehandlung, Kommentare, etc bedeuten grossen Anteil des Aufwandes)

> Produktion ist nahezu kostenneutral, Hauptkostenanteil liegt in der Entwicklungsarbeit

> Kleine Projekte werden direkt auf grosse umgerechnet

> Expertenschätzung: Alle Verfahren, die von mehr oder weniger Erfahrenen Personen ohne expilzit systematisches Vorgehen druchgeführt werden

> Delphi-Methode: Die Schätzung einzelner Personen wird gemittelt, das Ergebnis den Schätzern in einer Rückkoppelungsschleife zurückgegenen. Bei einem zweiten Durchgang muss jeder Schätzer grössere Abweichungen vom Mittelwert erklären. Solange iteriert, bis ein guter Konsens erreicht ist.

> Algorithmische Verfahren: Man darf sich nicht davon täuschen lassen, dass algorithmische Verfahren Objektivität suggerieren. Auch hier muss von abgeschätzten Ausgangsbedingungen aus zu Zeit- und Kostenschätzungen geschlossen werden. Dies allerdings erfolgt nach Berechnungsmodellen die durch Studien abgeleitet wurden und ev. durch Erfahrungen der abschätzenden Firmen selbst zu kalibrieren sind.

> COCOMO von Boehm geht von der geschätzten Codegrösse un der Art des Projektes aus. Die Codegrösse wir in Kilo Lines of delivered Code angegeben und die Art des Projektes kann aus dem Anwendungsbereich, für Programsysteme und für eingebettete Systeme gewählt werden. Für jeden Typ von Projekt gibt es andere Berechnungsformeln. Die Gleichungen ermitteln jeweils Man Month und Time to develop. Daraus ergibt sich eine leicht progressive Kurve. > Weiterentwicklung COCOMO 2

Die Pflegekosten sind ein beträchtliche Anteil der Kosten des Gesamtprojektes. Sie können durchaus gleich teuer wie die Entwicklungsaufwände werden. Je nach Zielmarkt: extreme Schwankungen. Werden in KDSI pro Person angegeben (eine Person als Vollzeitbeschäftigung kann 5000 Zeilen Code pflegen. 

> Kann heute nicht mehr so angewendet werden, da durch moeren SW Werkzeuge die Produktivität stark gestiegen ist.

> Qualität: Das Mass, in dem ein Satz inhärenter Merkmale Anforderungen erfüll

> Qualitätsmanagement: Aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität

> Aus Kundensicht: Spezifikation erfüll; Erwartungen erfüllt; Ressourcen optimal ausgenutzt

> Aus Ingenieurssicht: Verständlichkeit; Wartbarkeit; Zuverlässigkeit; Portierbarkeit; Wiederverwendbarkeit; Modifizierbarkeit; Effizienz; Benutzerfreundlichkeit

> Die SW Besonderheiten: Entwicklung ist komplex und teuer, Produktion nahezu kostenneutral; kaum Tradition für SW Entwicklung; schwieriger zu prüfen als materialle Produkte

Qualität kostet Geld, also nur Qulitätssicherungsmassnahmen, wenn es sich unter dem Strich lohnt. Prüfkosten steigen linerar mit dem Prüfaufwand. Es lohnt sich beispielsweise in der Medizin: Fehlerkosten sind unverhältnismässig viel höher.

> Qualität wird erzeugt, nicht erprüft

> Qualität bezieht sich auf Produkte und die zur Herstellung verwendeten Prozesse. Dies ist nicht trennbar

> Die Qualitätsverantwortung muss bei denselben Perosnen liegen, die auch die Ziet- und Budgetverantwortung tragen.

> Das Qualitätswesen misst nur die Qualität. Es erzeugt sie nicht, sondern gibt Empfehlungen für Massnahmen zur Erzeugung von Qualität

> Das Qualitätswesen muss einen unabhängigen Berichtspfad zur Unternehmensleitung haben, um das Abblocken schlechter Nachrichten zu verhindern.

> Es gibt zwei Typen von Review, den Walkthrough und die Inspektion.

> Beim Walkthrough erklärt der Autor einen begrenzten Abschnitt eines Dokumentes oder Quellcode. Die Anwesenden Experten nennen die Befunde, die ihnen bei diesen Erklärungen auffallen. > Bericht mit eventuelllen Massnahmen.

> Inspektion: Durchführung (Planung, Vorbereitung, Sitzung, Überarbeitung und Kontrolle); Rollen (Moderator, Schreiber, Gutachter, Autorenschaft); Regeln

> 2 Testarten: Black Box Test und White Box Test

> Beim Black Box Test ist der innere AUfbau einer Funktion uninteressant. Die Funktion wird geprüft, indem gezielt Parameterkombinationen beim AUfruf gewählt werden, bei denen vermutet werden kann, dass sie die kritischen Bereiche der Funktionalität überstreichen.

> Beim White Box Test werden Prameterkombinationen gewählt die dazu führen, dass ein möglichst grosser Anteil des Codes durchlaufen wird.

> Bei Simulationen wird ein Teilaspekt des Systems modelliert und nachgebildet. Mit dieser Nachbildung wird dann die SW getestet.

> Schwernachvollziehbare Änderungen am Dokument; Dokumentkonflikte

> Konfigurationsmanagement macht Änderungen an Dokumenten verfolgbar und kontrollierbar. Dies ersetzt grösstenteils lokale Datenhaltung von Dokumenten. Ist sozusagen ein Container, Dokument wird herausgeholt, bearbeitet und danach wieder in Container versorgt. Der Container vergibt Versionsnummern an einzelne Dokumente. Das neueste Dokument liegt immer zuoberst.

> abstrahierte Abbildung eines Systems, also Sichtbarmachen. Eingesetztes Werkzeug ist die UML.

> 14 hauptdiagrammtypen, Aufteilung in 2 Gruppen: statische und dynamische

> Anwendungsfälle (use cases) gehören zwar zu den dynamischen Diagrammen weil sie Abläufe beschreiben, zeigen aber nicht das System im Wechsel der Zeit. Sie werden benutzt, um zu beschreiben, was aktive Elemente (Nutzer, ander Systeme) mit einem System tun können

> Klassendiagramme, ebenfalls statische Diagramme, die die einzelnen Komponenten eines Systems darstellen

> Aktivitätendiagramme, ein Diagrammtyp aus der Gruppe der dynamischen Diagramme, die ähnlich wie Flussdiagramme, Vorgänge darstellen

> Zustandsdiagramme, die ebebfall dynamischer Art, zeigen durch welche Ereignisse oder Bedinungen ein System von einem Zustant in den nächsten wechselt

> Sequenzdiagramm, die als dynamischer Diagrammtyp den Austausch von Informationssequenzen darstellt.

> Eine Anwendung der extensible Markup Language

> Ein Vokabular, das aus Symbolen mit der ihnen zugewiesenen Bedeutung gebildet wird, ergänzt um Regeln zur Kombination der Vokabularelemente

> Anwendungen einer so neu geschaffenen Sprache werden als XML Dokumente bezeichnet

> XML ist kein Dokumentenformat, sondern eine Sprache zur Definition von Dokumentenformeten.

> XML ist: keine Programmiersprache; kein Transportprotokoll; keine Datenbank; einXML Dokument ist, es tut nichts, ist aus sich heraus passiv; XML wurde entworfen, um Daten zu strukturieren, zu speichern und zu transprotieren; 

Nach dem Festlegen, Ermittlung ob Richtung und Geschwindigkeit des Fortschrittes den Erwartungen entspricht. > Weiche Ziele: allmähliche Erfüllung, bis zu Prozentsatz erreicht > Harte Ziele: Erreicht oder nicht

Über ein Messverfahren werden Messwerte einer Skala zugeordnet. Diese Messwerte machen Aussagen über die gemessene Sache. Solche für SW verwendete Masse werden oft als Metriken bezeichnet. Beispiele für solche Metriken sind z.B. die Codegrösse oder die durchschnittliche Grösse von Funktionen. Wichtig ist die genaue Definition des Masses. Was z.B. ist Codegrösse? Zählel Leerzeilen oder Zeilen, die ausschliesslich Kommentar halten dazu oder nicht?

Die Skala, in der eine Metrik dargestellt ird, bestimmt, welche Aussagen mit einer Metrik gemacht werden können.

Manche Masse können direkt in Werten ausgedrückt werden. Diese Masse werden als direkte Masse bezeichnet. Andere Eigenschaften von SW wiederum können nur mit immensem Aufwand oder gar nicht in Werten angegeben werden. Ein Beispiel ist die Codegrösse. Für manche solcher Masse kann amn Indikatoren angeben. Solche Masse heissen indirekte Masse. Die Portabilität einer SW kann hier als Beispiel dienen. Die Anzahl an Codezeilen mit Betriebssystemaufrufen, die Anzahl HW- oder betriebssystemabhängiger Module oder die Anzahl an Codezeilen, die nicht dem Standard entsprechen, sind hier Indikatoren (z.B. Masse in % ausgedrückt)

Hier interessieren vor allem Masse, die die Funktion betreffen wie die Erfüllung der Spezifikation, Zuverlässigkeit, Benutzerfreundlichkeit und Wartbarkeit. DIe meisten dieser Masse können nur indirekt gemessen werden.

Wichtig sind Aufwand, Projektdauer, Fortschritt und Kosten für Entwicklung und Fehler. Das direkte Messen ist bei diesen Merkmalen meist einfacher.

> Eine Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. 

> Eine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen.

> Die Zusammenstellung aller Anforderungen an eine Software. Synonyme: Anforderungsdokument, Software Requirements Specification.

> Der Prozess, der mit dem Gewinnen von Anforderungen verbunden ist, heisst Requirements Engineering

> Das systematische, disziplinierte und quantitativ erfassbare Vorgehen beim Spezifizieren, d.h. Erfassen, Beschreiben und Prüfen von Anforderungen an Software.

> Verstehen und Beschreiben, was die Kunden wünschen oder brauchen

> Spezifikation und Verwaltung von Anforderungen mit dem Ziel, das Risiko zu minimieren, dass Software entwickelt wird, welche den Kunden nicht nützt oder gefällt

>> Häufig heissen die Anforderungsspezifikationen auch Pflichtenhet. Dieser Begruff ist jedoch nicht allgemein definiert und wird häufig von verschiedenen Partnern verschieden interpretiert.

Ein SW-System muss gegenüber seiner Umgebung zuerst abgegrenzt werden. Eine SW ist eine spezielle Lösung, die durch Schnittstellen mit der Umgebung kommuniziert. Die Aspekte ausserhalb der Schnittstellen sind die Umgebung oder der Kontext eines Systems. Der Kontext, der betrachtet wird, besteht jedoch nicht aus der gesamten Systemumgebung, sondern nur aus Komponenten, die von Bedeutung für das zu entwickelnde System sind. Die Systemspezifikation beinhaltet folglich die Bestimmung der Grenzen und das gewünschte Verhalten des Systems innerhalb der Schnittstellen. Ausserdem müssen die Randbedingungen gefunden werden, unter denen das System seine Funktion zu erfüllen hat

RE gliedert sich in zwei Hauptteile: 

> Spezifikation

> Verwaltung

Spezifikation gliedert sich in: 

> Gewinnung

> Analyse

> Dokumentation

> Prüfung

Kein formalisierter, genormter Prozess. Individueller Zuschnitt für jedes Projekt.

Achten auf: 

> brauchen wir einen linearen oder einen inkrementellen Prozess?

> Soll die Spezifikation ein Vertrag mit dem Partner sein?

> Sind die Kunden und/ oder Nutzer bekannt?

> Gibt es einen Kundenauftrag?

> Kann Standardsoftware das Problem lösen?

Die Hauptunterscheidung liegt zwischen den Projekt- und den Produktanforderungen.

> Produktanforderungen: funktionale Anforderungen (bestimmen das "was" ) und nicht-funktionale Anforderungen (bestimmen das "wie")

> Leistungsanforderungen (Rechenzeiten, Datenmengen, besondere Qualitätsanforederungen legen Zuverlässigkeiten oder auch Benutzeraspekte fest.

> Randbedingungen: Gesetze, andere Bestimmungen wie Normen, Schnittstellen

Priorisierung von Anforderungen:

> Muss-Anforderungen (def. zu erfüllen)

> Soll-Anforderungen (bei zu hohem Aufwand nicht verpflichtend)

> Wunsch-Anforderungen (nur bei entspr. niedrigen Kosten zu verwirklichen)

Funktionale Anforderungen:

> Daten, Funktionen, Verhalten, Fehlerreaktionen

Nicht-funktionale Anforderungen:

> Leistungsanforderungen: Datenmengen, Reaktionsgeschwindigkeiten, Durchlaufzeiten

> Qualität: geforderte Qualitäten

> Randbedinungen: Schnittstellen, Normen und Gesetze, Datenschutz/-Sichtung, spezielle Angaben des Kunden

>> kann sich je nach Unternehmen unterscheiden

> Jede Anforderung braucht eine eindeutige Identifikation

> Anforderungen kurz halten. Nur eine Aussage pro Anforderung

> Funktion und Parameter für gewünschte Resultate angeben

> Aunahmen angeben

> implizierte Annahmen explizit formulieren

> wo immer möglich, Zahlen angeben. Erleichtert die Prüfung

> Skeptisch mit allgemeinen Angaben umgehen

> Redundanz vermeiden

> Präzision in den Formilierungen so weit, dass Missverständnisse vermieden werden

> Natürliche Sprache: Vollstädnige Sätze; Jedes element mit Potential z Missverstädnnissen muss im Glossar eine Definition erhalten; Nominalisierung (Berechnung) vermeiden; Anforderungen als Hauptsatz, Erläuterungen evtl als Nebensätze

> Algebraisch: deskriptive, formale Methode. Funktionen werden deklariert und beschrieben und dann das Verhalten in mathematischen Sätzen ausgefrückt

> Datenfluss orientiert: Strukturierte Analyse ist datenflussorientiert und eine konstruktive Beschreibung. Die Datenflüsse durch ein System werden analysiert, in kleinere Module zuerlegt und dies so lange fortgesetzt, bis die Einheiten klein genug sind, um sie als einzelne Anforderungen aufzufassen.

> Automaten: konstruktiv und teilformal

> Objektorientiert: Abbildung des Systems als Kollektion von Objekten; zusammenfassung der objekte in Klassen

> Analyse

> Spezifikation

> Design

> Implementierung

> Test

> Nutzung

>Ablösung

> Tätigkeit: Analyse der vorhandenen Informationen; Betimmung vorhandener Strukturen mittels definierter Techniken; Schriftliches Fixieren der gewonnen Einsichten

> Produkt: Diagramme; Text; andere mehr oder weniger formale Dokumente die die in der Analyse gewonnnen Einsichten darstellen

> Tätigkeit: Ermittlung der vom Kunden gewünschten/gebrauchten Fähigkeiten des SW Produktes durch mehr oder weniger formalisierte, definierte Techniken wie Interview oder use cases

> Produkt: formale Spezifikation, je nach verwendetem Prozessmodell mehr oder weniger ausführlich und vollständig

> Tätigkeit: Entwurf der Architektur; Design der Subsysteme/Units

> Produkt: Beschreibung der Architektur in möglichst formaler Art und Weise; Schnittstellenbeschreibung; Beschreibung von Algorithmen (z.B. mit Struktogrammen, Interaktionsdiagrammen oder Aktivitätsdiagrammen)