Software Engineering (Fach) / Kapitel 1 (Lektion)

Semester 3. Wirtschaftsinformatik FH Kiel

Diese Lektion wurde von winfomate erstellt.

Lektion lernen

zurück  |  weiter 1 / 1

• Misserfolgsfaktoren von Softwareprojekten (5) 1. Keine Unterstützung durch das Top-Management 2. Unzureichende Beteiligung der Auftraggeber 3. Unvollständige Anforderungen 4. zu wenig Ressourcen (Finanziell / personell) 5. Unklare Projektziele
• Ziele des Softwareengineerings 1. Effektivität (Ziele sollen erreicht werden 2. Effizienz (z.B. Einhaltung von Budgetvorgaben) 3. Usability 4. Veränderbar- und Wartbarkeit
• Alpha Cards (5) 1. Requirements (-> Anforderungen identifizieren bis Nutzungsbereites System) 2. Software Systems (-> von Arichtektur vorbereitung, System im Einsatz bis Einstellung) 3. Work (-> Planung, Risikomanagement, Controlling, Übergabe, Revision) 4. Team (-> Forming, Norming, Performing, Adjourning) 5. Way of Working (-> Prinzip (z.B. SCRUM), Umsetzung, Prinzip wird ohne Nachdenken umgesetzt, keine weitere Benutzung) 6. Opportunity (-> Die "Gelegenheit" ein Softwaresystem zu entwickeln oder zu ändern. 7. Stakeholder (-> Personen oder Gruppen die das Softwaresystem beeinflussen oder durch dieses beeinflusst werden)
• Software Prozesse -> Ziele (der Vorgehensmodelle) 1. Erhöhung der Projekttransparenz 2. Verbesserung der Planbarkeit 3. Erleichterung der Projektdurchführung
• Wasserfallmodell (sequentiell) Anforderungsanalyse -> Systementwurf -> Implementierung -> Integration -> Betrieb/Wartung - streng sequentiell - Review am ende jeder Phase pro: Einfaches Projektcontrolling/-management pro: Strikte Trennung zwischen Entwurf und Implementierung kann zu besserer Systemarchitektur führen contra: Ungeeignet in großen Entwicklungsprojekten contra: Lange "Lieferzeiten"
• Evolutionäres Modell (iterativ, inkrementell) - Anfangsversion auf Basis von teilweise festgelegten Anforderungen - Version wird von Anwender kommentiert und ergänzt - Sukzessive Entwicklung der Endversion aus Zwischenversionen pro: Anfangsversion früh verfügbar pro: Geeignet, wenn Endprodukt nur teilweise spezigiziert ist contra: Architekturentwurf nicht konstant (Refactoring notwendig) contra: Anforderungen werden umfassender - Tendenz zur "Mercedes Software"
• Spiralmodell (iterativ, inkrementell) Eine Spirale von Innen (erste Anforderungen und start der Entwicklung) nach Außen (nach ersten Prototyp kommt das alpha) bis hin zum Endprodukt am Ende der Spirale. 1. Planung 2. Risikoanalyse 3. Entwicklung 4. Evaluation des Kunden
• Risikomanagement - Prozess Bewertung 1. Risikoerkennung 2. Risikoanalyse Kontrolle 3. Planung der Maßnahmen 4. Risikoverminderung 5. Risikoüberwachung Risikoanalyse als Graphen mit x= Auswirkung (gering-> hoch) und y= Eintrittswahrscheinlichkeit (gering -> hoch)
• Spiralmodell Vor- und Nachteile pro: Einbeziehung der Projektrisiken pro: Flexibles Modell contra: Risikoanalyse schwierig (Bedarf Erfahrung) contra: Hoher Managementaufwand
• Vor- und Nachteile der inkrementellen Entwicklung allgemein pro: Frühzeitige Nutzung von System funktionalität pro: Risiko eines Projektabbruchs ist sehr gering pro: Intensiverer Test hochpriorisierter Systemfunktionalitäte contra: Schwierigkeit "geeignete" Ausbaustufen zu definieren
• Agile Softwareentwicklugn - Vorteile - Transparenz (Wo stehe ich im Projekt?) - Flexibilität (Änderungen von Anforderungen) - Lernen durch ständiges Feedback - Zusammenarbeit & Kommunikation der wesentlichen Stakeholder
• SCRUM Rollen: - Produkt Owner .Legt die Eigenschaften des Produktes fest und priorisiert diese aus Sicht des Geschäftswerkes im Product Backlog .Legt Funktionsumfang und Auslieferungstermin fest .Nur eine Person - SCRUM - Master .Coach für die eingesetzten Techniken .Wendet äußere Störungen ab und repräsentiert das Team nach außen .Darf NICHT inhaltlich arbeiten und ist NICHT teil des Teams - Team (5-9 Personen) .Mitglieder übernehmen selbstständig Aufgaben .Gemeinsames Ziel/Selbstloses Handeln
• SCRUM Meetings - Spring Planung - Sprint Review (Ergebnisse präsentieren) - Sprint Retrospektive (Entwicklungsprozess) - Daily Scrum Meeting (max. 15 Minuten) -> Nur Team und Scrum Master dürfen reden Sprint Dauer 2-4 Wochen Am Ende eines Sprints existiert immer ein auslieferbares Softwareprodukt
• SCRUM Artefakte - Product backlog (Product Owner schreibt ihn nicht alleine, priorisiert aber die Backlog Items) -> kein Spezifikationsdokument - Sprint backlog (Aufwandsschätzung der Items, Items/Tasks erarbeiten im Team)die Aufwandsschätzung kann mithilfe eines Planning Pokers gemacht werden - Burnout Diagramm (Zeigt den Fortschritt im Sprint mit Hilfe des Restaufwandes für die Sprinttasks an)
• Produktanforderungen - Arten - Funktionale Anforderungen -> Vom System bereitzustellende Funktion - Qualitätsanforderungen -> qualitative Eigenschaften, die erfüllt werden sollen - Randbedingungen -> Organisatorische, technologische Einschränkungen
• Anforderungsklassifikation nach Kano y-Achse: unzufrieden zu sehr zu frieden x-Achse: Erwartung nicht erfüllt -> Erwartung übertroffen  -x & -y bis +x & -y : Basisanforderungen -x & -y bis +x & +y : Leistungseigenschaften -x & +y bis +x & +y : Begeisterungsanforderungen
• Anforderungsermittlung - Quellen - Stakeholder - Dokumente - System im Betrieb
• Anforderungsermittlung - Problemfelder - Stakeholder kennen nicht alle Anforderungen bzw. können diese nicht beschreiben - Stakeholder kommunizieren unterschiedlich (z.B. IT`ler und BWL'er) - Stakeholder haben widersprüchliche Anfoderungen
• Stakeholderanalyse 1. Identifizieren 2. Erwartungen feststellen 3. Einfluss Abschätzen 4. Betroffenheit / Motivation abschätzen 5. Maßnahmen planen Maßnahmen: x-Achse: Motivation -> hoch y- Achse: Einfluss -> hoch - niedrig & niedrig  = Beobachten - wenig(x) & hoch = Zufriedenstellen - hoch(x) & wenig = Informieren - hoch & hoch = Zusammenarbeit
• Anforderungsermittlung - Techniken - Artefaktbasiert -> Dokumentenanalyse -> Nutzungsdaten bestehender Systeme -> Wiederverwendung (generischer Anforderungen) - Stakeholderbasiert: -> Befragungstechniken (Interviews, Fragebogen, etc.) -> Kreativitätstechniken (Brainstorming, Morphologische Analyse) -> Beobachtungstechniken (Feldbeobachtung, Lehrlingsrolle)
• Prototyping : Arten der Entwicklung - Explorativ -> Vollständige Systemspezifikation - Experimentell -> schmaler Ausschnitt des Systems - Evolutionär -> schrittweise entwickeln des Prototypen Grafik RE_Teil1 S. 49
• Architekturziele 1. Wartbarkeit schneller Fehleranalyse, schnelle Anpassung, Stabilität 2. Flexibilität Varianten von Geschäftsprozessen, Baukastenprinzip, Skalierbarkeit 3. Modularität lose Kopplung, Single Responsibility Principle 4. Hierarchisierung
• Software Prozess (Vorgehensmodell) Definition - legt die Prozessabfolge der Aktivitäten fest (WANN?) - Spezifiziert, welche Entwicklungsartefakte und wie zu erarbeiten  sind (WAS und WIE?) - weist Aktivitäten und Artefakten Projektrollen zu (Verantwortlichkeit) (WER?) - beinhaltet Kriterien, die ein Monitoring des Projektfortschrittes sowie eine Beurteilung der Qualität der Artefakte ermöglichen sollen
• Qualitätskriterien von Software - Konsistenz (Inhalte sollten sich nicht widersprechen - Verständlichkeit (Eindeutige Verständlichkeit für jeden) - Vollständigkeit - Verifizierbarkeit (Eindeutige und klar definierte Anforderungen) - Nachvollziehbarkeit
• Risikoarten - Geschäftsrisiken - Technische Risiken - Termin- /Kostenrisiken - Risiken im Projektvorgehen - Personenrisiken - Lieferantenrisiken .....
• IBM Rational Unified Process (RUP) - Softwareprojekt wird in zwei Dimensionen eingeteilt (Projektphasen, Aktivitäten der Softwareentwicklung) - Zeigt in welcher Projektphase wie viel Aufwand je Disziplin (z.B.  Anforderungsanalyse, Implementierung) steckt
• Extreme Programming Prinzipien - PlanungspielPlanungsspiel (Hauptmethode um Anforderungen zu erheben. Stakeholder erklären in Userstory welches Ziel sie verfolgen) - Verwendung eines Glossars (Begriffsdefinitionen für gleiches Verständnis im Projekt) - Regelmäßige Validierung (Direkt nach der Entwicklung in den Test) Refactoring (Methode zur systematischen Restrukturierung von Programm-Code, bei der sich das Verhalten der Software aus Anwerdersicht nicht verändert)(Zweck: entstandenen Code zu vereinheitlichen und Fehlerbehebungen & Weiterentwicklung ermöglichen) - Paar-Programming (Zwei Entwickler arbeiten an einem Rechner, um gemeinsam eine Aufgabe zu lösen --> Steigert die Qualität des Codes) - Kontinuierliche Integration (fortlaufende oder permanente Integration beschreibt den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung)(Fehlersuche & Fehlerbehebung viel effizienter, da sofort bei der Integration Fehler gefunden werden) - 40-Stunden-Woche - Klare Programmierrichtlinien - Gemeinsamer Codebesitz - Permanent verfügbarer Kunde - Kleine Releases
• Requirements Engineering Anforderungen, was das System leisten soll - Strukturierter, systematischer Umgang mit Anforderungen 1. Ermitteln 2. Dokumentieren 3. Validieren 4. Abstimmen (Priorisieren) - Ziele als Basis für das Projekt (S.M.A.R.T. formulieren)
• SMARTE Ziele - specific (Eindeutig und klar) - measureable (messbar und testbar um den Grad der Zielerreichung zu messen) - accepted (muss von Stakeholdern akzeptiert werden) - reasonable (Müssen erreichbar sein und keine Utopien) - time-bound (Ein Zeitpunkt sollte definiert sein, an dem man das Ziel erreichen möchte)
• Use-Case-Diagramm - Definition Ein Use Case Diagramm ist eine Darstellung, die das Verhalten eines Systems aus Anwendersicht visualisiert. Es ist eine grafische Repräsentation von Anwendungsfällen inklusive deren Beziehungen zur Umwelt und zu anderen Anwendungsfällen. Damit beschreibt ein Use Case Diagramm – auch Anwendungsfalldiagramm oder Nutzfalldiagramm genannt – in einer hohen Abstraktion, welche Funktionen und Dienste ein System für einen Anwender bereitstellt.
• Use Case - Elemente Akteur: .Alle Beteiligten (Stakeholder) eines Vorgang .Eine Rolle, die sich außerhalb des Systems des zugehörigen Anwendungsfalles befindet und mit dem System, beschrieben durch seine Anwendungsfälle, interagiert .Muss keine echte Person sein, dann aber Abstrakter Akteur Beziehungen: .Anwendungsfälle können in einer Beziehung zu einem Akteur stehen
• USE CASE - Anwendungsfallbeziehungen - Include (Enthält-Beziehung) .Ein Anwendungsfall wird in einem anderen Anwendungsfall eingebunden .Zwingende Beziehung "Mussbeziehung" - Extend (Erweiterungsbeziehung) .Ein Anwendungsfall kann unter bestimmten Umständen durch einen anderen Anwendungsfall erweitert werden .Optionale Beziehung "Kannbeziehung" - Generalisation (Generalisierungsbeziehung) .Hierarchische Beziehungen zwischen Anwendungsfällen

zurück  |  weiter 1 / 1