SoftwareIngeneering_FOM

1. Problemlose Erweiterung möglich. 2. Verhaltensänderungen möglich -> nicht stabil!

_ Analyse _ Spezifikation der Anforderungen _ Architekturentwurf,SpezifikationderModule _ Codierung und Modultest _ Integration,Test,Abnahme _ Betrieb und Wartung _ Auslauf und Ersetzung

fixe Entwicklungskosten + variable Betriebs- und Wartungskosten = Gesamtnutzen (monetärer Nutzen [Lizensverträge, Produktivität] + nicht messbarer Nutzen [Zufriedenheit, Image])

Analyse => Betrieb Spezifikation => Installation Entwurf => Integration Codierung => Modultest Eingabe => Übersetzung ZIEL: Fehler frühzeitig finden (GRUND: Wenn Anforderungsfehler erst in Codierung gefunden werden, muss der Entwurf auch erst wieder gerade gezogen werden… )

Abbilder von etwas oder Vorbilder fu_r etwas; sie werden auch als - deskriptive (beschreibende) Bsp: Foto von mir beschreibt wie ich zur Zeit x aussah - pra_skriptive (vorschreibende) Bsp: Bauplan des Gebäude, solang es noch nicht fertigt gebaut (existiert) wurde Modelle bezeichnet.

+ Abbildungsmerkmal (zum fiktiven, geplanten oder bestehenden Original gib es ein Modell) + Verkürzungsmerkmal (weggefallene präterierte Attribute des Originals werden durch abundante Attribute des Modells ersetzt) Bsp: Foto, präteriert sind Körpergewicht, abundant sind Kopierpapierqualität + pragmatisches Merkmal (Modell kann unter gewissen Umständen/Fragestellungen das Original ersetzen) Bsp: Unfallfoto kann Unfallanwesenheit ersetzen

vom + IST-Zustand über + das präskriptiven Modell per Modellierung über + deskriptive Modell per Realisierung zum + GEPLANTEN Zustand

- Modell, bei dem alle Informationen von Objekt bis auf eine verkürzt wird, wodurch absolute Vergleichbarkeit von mehreren verschiedenen Objekten hergestellt wird - passiert durch eine Skala

No Or In Ra Ab + Nominalskala (ungeordnete Obstkiste) + Ordinalskala (nach Vorliebe geordnete Obstkiste ohne Nullpunkt und Abstand) + Intervallskala (Obst nach Vorliebe mit Abständen sortiert) + Rationalskala (Obst nach Vorlieben mit Abstand und VorliebenNullpunkt sortiert) + Absulutskala (Obstkiste ohne Obst mit absoluten Werten gefüllt, Reihenvolge, Abstand, Nullpunkt)

- Arbeitsbedingungen (technische Ausstattung, interne wie externe Störungen) - Schwierigkeiten der Aufgaben (Neuigkeitsgrad der Aufgabe, Lösungsverfügbarkeit, Komplexität des Zielsystems, klare und stabile Anforderungen verfügbar?) - Projektrahmenbedingungen (personelle Kontinuität, Arbeitsklima, Verteilung der Aufgaben und Kompetenzen, stabile und zuverlässige Führung, Zeit-/Kostendruck) - Eignung der Entwickler für das Projekt (Verständnis, Erfahrung mit der Anwendung Thechnologie und Problem) - individuelle Faktoren (Disziplin, Motivation, Teamfähigkeit)

Ein Projekt... - ist zeitlich begrenzt - hat einen Erzeuger - hat ein Ziel bzw. ein Büdel von Zielen, woraus ein bestimmtes Produkt resultiert. Wenn Ziele erreicht werden, ist es erfolgreich. - hat einen Kunden bzw. Abnehmer, dem das erzeugte Produkt dann gehört - verbindet Menschen, Resultateund Hilfsmittel

Kleine  Teams  und  „Einzelka_mpfer - schlecht kontrollierbar, durch fehlendes Feedback beisp. schwierige Dokumentation, Einarbeitung der Vertretung bei Ausfall, + wenig Overhead, keinen Kommunikationsaufwand Anarchische Teams (keine festgelegte Hirarchie) - Standarts schwer durchsetzbar bzw. selten eingehalten, Einführung neuer Methoden ect. von Entwicklerlaune abhängig, nicht lernfähige Organisation, unplanbar + selbstbestimmtes arbeiten, keine Bürokratie Demokratische Teams, geleitet durch den primus inter paris - durch Demokratie riesiger Overhead bzw. hoher Kommunikationsaufwand, Fraktionen können entstehen + durch Demokratie zwar zufriedene Mitarbeiter, frühzeitige Problemerkennung Hierarchische Teams (hat Projektleiter als Instanz für Leitung, Fortschrittskontrolle, QS) - lange Kommunikationskette (späte, unvollständige oder ausfallende Kommunikation) und ggf. "magischer Farbverschiebung", desinformierte und demotivierte Indianer + leichter Mitarbeiterwechsel, Übersichtlichkeit durch ggf. Baumstruktur Chief-Programmer-Teams (Vorarbeiter bildet Architektur, ist technischer Leiter, überprüft Team, ist in Gesamtentwicklung eingebunden, hat ggf. Stellvertreter) - hohe Ansprüche werden an Vorarbeiter gestellt wodurch Ausfallrisiko entsteht, Erfolg steht und fällt mit der Person des Vorarbeiters + Effizienz, kurze Kommunikations- und Entscheidungswege

... wenn Projekt -  definierten  Resultate - in der geforderten Qualita_t - innerhalb der vorgegebenen Zeit und mit den vorgesehenen Mitteln erzielt UND _ Aufbau oder die Versta_rkung eines guten Rufs _ Aneignung von Kenntnissen, die zuku_nftig beno_tigt werden _ Entwicklung wiederverwendbarer (weil lukrativer zwecks Wiederverkauf) Komponenten _ Wahrung eines attraktiven Arbeitsklimas fu_r die Mitarbeiter

Ein Problem, das - noch nicht eingetreten ist, - aber wichtige Projektziele oder Projektergebnisse gefa_hrdet, falls es eintritt. - Ob es eintreten wird, kann nicht sicher vorausgesagt werden.

_IAPVG_ Risikomanagement umfasst alle Aktivitäten, die darauf abzielen, dass aus einem Risiko kein schweres Problem fu_r das Projekt wird. Im Einzelnen zählen dazu: - Identifikation von Risiken - Analyse und Bewertung der Risiken - Planung von Gegenmaßnahmen - Verfolgen der Risiken und der gewählten Gegenmaßnahmen

+ aus Sicht des Projektleiters: unzielstrebige demotivierte Mitarbeiter, fehlendes Kostenbewusstsein und Zielverständnis, arrogante Spezialisten + aus Sicht der Mitarbeiter: Desinformation über ProjektstandÄnderungenRahmenbedingungen, fehlende Anreize, ignorierte persönliche Interessen, von einander getrennte AufgabenVollmachtVerantwortlichkeiten, fehlende inkompetente Führung, fehlende Konsequenzen, schlechte Rahmenbedingungen

- Mangelnde Ausbildung - Unrealistische Managementerwartungen hinsichtlich Termine & Budgets - Implizite Kundenerwartungen - Verhalten der Mitarbeiter durch fehlende Informationen - Eigener Anspruch und dadurch ggf. Überarbeitung

+ Kalkulation und Angebotserstellung + Personalplanung und mittelfristige Disposition + Vorbereitung  einer  Entscheidung  „make  or  buy“ + Nachkalkulation bei ChancheRequests oder Projektverlängerungen

Expertenscha_tzung + Fachleute nutzen ihre Erfahrung, um den Aufwand zu scha_tzen - großer sozialer (durch hirarchische Stellung) und subjektiver Faktor fließt in die eigentliche Kostenschätzung ein, unsystematisch, schlecht dokumentiert Algorithmische (auf Berechnungen basierend) Scha_tzung + Kosten werden aus frühzeitig bekannten bzw. leichter/genauer als der Gesamtaufwand zu schätzenden Gro_ßen berechnet, spezielle günstige/ungünstige Umstände können durch Einflussfaktoren einbezogen werden E = Aufwand, T = Zeit, H = Mitarbeiter E = M * 3,0 (200 KDSI / KDSI) ^ 1,12 = 1,71 * 3,0 * (200)^1,12 E = 1937,63 PersonenMonate T = 2,5* (1937,63PM / PM)^0,35 T = 35,36 CMonate H = 1937,63 / 35,36 = 54,79 Heads (Entwickler)

1. Anforderungen werden sorgfältig erhoben und unterwegs nicht verfälscht 2. in der Spezifikation formuliert, gepru_ft, 3. in den Entwurf umgesetzt 4. implementiert, auf verschiedenen Ebenen gepru_ft und korrigiert durch einen weit entfernten anders denkenden und sprechenden Entwickler 5. Resultat geht zuru_ck an den Klienten

Eselsbrücke: zuerst L, dann P laut lexikographische Ordnung + Lastenheft = Ergebnis der Anforderungsanalyse und Voraussetzung für die Spezifikation, Inhalt ist unklar definiert, Anforderungssammelsurium ist Synonym für Lastenheft, beinhalet die fachlichen Anforderungen aus Klientensicht (Lücken, Unklarheiten, Widersprüche sind daher normal), + Pflichtenheft = entsteht aus Ausarbeitung aus dem Lastenheft, stellt die eigentliche Anforderungsspezifikation dar, ist detailiert und gefiltert, ohne Umsetzungs- oder Implementierungsdetails

= undankbare Feststellung des bestehenden Zustands, um neues Systems mindestens so stark wie aktuelles System werden zu lassen, hervorgerufen durch implizite Erwartung des Klienten dass das Gute ja erhalten bleibt!

= komplette Veränderungsaufnahme am bestehenden System bzw. komplette Kundenwunschaufnahme bei Neuimplementierung zwischen Analytiker und Klienten mit Kundenwuschzettel als Ziel
- Kein Filtern/Aussortieren in der Analyse.
- Bewertung und Filterung der Kundenwu_nsche anschließend
UND
in Zusammenarbeit mit dem Kunden, um technisch/finanziell unrealistische Anforderungen bzw. allg. unvereinbare Anforderungen zu finden und ggf. durch Anforderungsreduzierung und/oder Budgeaufstockung zu lösen

+ Analytiker:
- Anforderungen zu u_bersehen
- eigene Vorstellungen einzubringen, die nicht die des Klienten sind
- Eventuell muss der Analytiker sogar damit rechnen, vom Klienten getäuscht zu werden Bsp: über bewusste Schwachstellen des alten Systems wird nicht informiert, um weiterhin Kaffeepause dem Zeitsystem unterzujubeln
- mangelde Motivation des Klienten die Analyse zu unterstützen wegen fataler Einsparungspotentiale
- wo Spezifikation unwichtig ist, wird auch Analyse der Kundenwünsche unwichtig sein

+ Klienten:
- Analytiker denkt, besser und erfahrener als Klient zu sein
- Analytiker will Veränderung, wobei Klient nur Verbesserung wollte

- während Analyse wird auch das Begriffslexikon angelegt

- dieses wird während der gesamten Software-Entwicklung verwendet und ergänzt.

- beinhaltet für das gemeinsame Projektverständnis bedeutende bzw. missverständliche Definitionen und Begriffe (Performance) und aus den Gesprächen und Interviews abgeleitet, widersprüchliche Bedeutungen müssen aufgezeigt und abschließend definiert werden

- weitere Bestandteile: Begriff und Synonyma aus Spezifikation, allgemeine Bedeutung (Definition, Erkla_rung), begriffliche Abgrenzung, Gu_ltigkeit (zeitlich, ra_umlich, sonst), Fragen der Beziehung zueinander, noch ungeklärte Unklarheiten, verwandte Begriffe (Querverweise)

- als Teil der Spezifikation bzw. des Spezifikationsdokuments wird zur Unterstützung und zur Verringerung bzw. Verhütung von Verständnisproblemen zwischen Analytiker und Klient

+ Offene und latente Anforderungen

(Offen: Vom  Kunden  bereits  „druckreif“  definiert. Latente: unbewusste Klientenanforderungen, nur mit Analytikerhilfe ersichtlich)

+ Entwickler-Option

(Dem Kunden ist die Lösung einer Anforderung gleich. + Unbedingt  notieren,  sonst  „Lu_cke“  in  der  Spezifikation)

+ Harte und weiche Anforderungen

(Harte: in Zahlen oder mit Ja/Nein beantwortbar + Weiche: Fließender U_bergang zwischen wahr und falsch)

+ Objektivierbare und vage Anforderungen

(Objektivierbar: pru_fen das Resultat gegen die Spezifikation. Vage: nicht gegen die Speks prüfbar wie bsp. Speicherverbrauch)

+ Funktionale und nichtfunktionale Anforderungen

(Funktional: zwingend benötigte durch den Programmnamen ableitbare Funktion + Nichtfunktional: alle nicht direkt die Funktion betreffende Systemanforderungen bsp: Antwortzeitverhalten, Wartbarkeit, Look-and-Feel - Anforderungsarten lassen sich weder auf gleiche Weise erheben noch dokumentieren oder pru_fen lassen