15335183
| Questão | Responda |
| Update Patch | Einzelnen Fehler oder einige wenige Fehler korrigiren |
| Update Hot-Fix | -Spezialfall: „Feuerwehraktion“ systematische Wartung muss folgen |
| Update Service Pack | Fehlerkorrekturen und verbesserte oder neue Funktionalitäten enthalten |
| Update Kumulative Combo Upgrades | enthalten auch vorhergende Upgrades |
| Verschleiß von Software (4) | 1. Fehler enstehen nicht durch abnutzung (werden eingebaut) 2. kann beliebig oft kopiert werden, Kopie und Original sind völlig gleich 3. Software ist digitales Gut 4. Wird nicht gefertigt sondern entwickelt |
| Vorprojekt (3) | Spezifikation, Grobentwurf AUfwands-/Kostenabschätzung Abschätzung der Auswirkungen und Folgen |
| Wartbarkeit | mit welcher Energie und welchem Erfolg Änderungen an der Software gemacht werden können |
| Werkstoffe der Software | Sprachen (meist natürliche Sprache und Programmiersprache) |
| Zuverlässigkeit | Die Wahrscheinlichkeit einer fehlerfreien Arbeitsweise einer Software für eine bestimmte Zeitdauer in einer bestimmten Umgebung |
| Agile Charter (3) | Vision Mission Success Criteria |
| Anforderungen Spezifikationsmethoden (textuell) | -Ablaufmodell -Anwendungsfälle -Begriffsmodell -Datenmodell -Strukturmodell -Verteilungsmodell -Zustandsmodell |
| Nicht funktionale Anforderungen | Wartbarkeit Zuverlässigkeit Leistung und Effizienz (Alle Anforderungen die sich nicht auf eine Funktion beziehen) |
| Anforderungssammlung Probleme | - Kunde kommuniziert Anforderungen ungenau - Entwickler interpieren die Aussage des Kunden falsch - Offene Punkte werden nicht abgeklärt |
| Anwendungsfälle | Name Ziel Vorbedingung Nachbedingug Nachbedingug im Sonderfall Akteure Normal Ablauf Sonderfall a b c |
| Backlog Product | Enthält Anforderungen Liste aller gewünschten Projektarbeiten Ideal: jeder Eintrag wertvoll für Benutzer oder Kunde Vom Produkt-Owner priorisiert Zu Beginn jedes Sprints re-priorisiert |
| Backlog Sprint | Tasks identifizieren und abschätzen (1-16h) In der Gruppe |
| Benutzbarkeit/Brauchbarkeit | Effektivität zur Lösung der Aufgabe Effizienz der Handhabung des Systems Zufriedenheit der Nutzer |
| Break-Even Point | Schnittpunkt zwischen Gesamtnutzen und den Betriebs-und Entwicklungskosten |
| Burn-Down-Chart | Visualisierung geleisteter und noch verbleibender Arbeit |
| Defensive Programmierung | Programmirstil zum vermeiden von Fehlern Fehler im Hinterkopf behalten (präventive Maßnahme) |
| Denkprinzipien Kostenbewusstsein | Nutzen hoch, Kosten gering Problem: Meist kein günstiges Preis/Leistungsverhältnis |
| Denkprinzipien Rationalität | Alles erklärbar, was nicht erklärbar ist, wird nicht akzeptiert |
| Denkprinzipien Problemlösen | Igenieur löst Probleme durch techn. Veränderungen Naturwissenschaftler versucht Probleme zu erkennen und zu vermeiden, natürliche Phänomene verstehen und erklären |
| Denkprinzipien Universeller Anspruch | Fachgrenzen gibt es für ein Entwickler nicht |
| Denkprinzipien Qualitätsbewusstsein | Hohe Qualität ist ein Prinzip der unspezifischen Kostensenkung |
| Denkprinzipien Normen (werden immer beachtet) | passende Schnittstellen, auch für Verfahren und Begriffe |
| Denkprinzipien Baugruppen | Lösungen der Teilprobleme werden ausgeklammert |
| Design by Contract | managt reibungsloses Zusammenspiel von verschieden Programmmodulen durch formale Verträge zur Verwendung der Softwareschnittstellen |
| Design Patterns (Entwurfsmuster) | bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme in der SE. Schaffen eine begriffliche Basis und Terminologie für Kommunikation über solche Probleme |
| Design Patterns Beispiele | Null-Object Singleton Composite Factory-Methode |
| Design Patterns Vorteile | Wiederverwendbarkeit Standardisierung Erhöhung von Verständlichkeit |
| Drei Schichten Architektur | Arbeitsschicht - Präsentationsschicht Anwendungsserver -Anwendungsschicht -Datenerhaltungsschicht Datenbankserver -DBMS |
| EDV-Projekt | Im eigenen Haus für den eigenen Bedarf entwicklt |
| Fehler Terminologie | Entwickler -> Fehlerhandlung -> Fehlerursache -> Fehlerzustand -> Ausfall |
| Defekt | Sammelbegriff für Fehlerursache und Ausfall (Fehlerwirkung) |
| Fehlerhandlung | Produzieren eines Fehlers im Code |
| Fehlerursache | Fehler im Code |
| Fehlerzustand | Fehler der durch den ausgeführten fehlerhafen Code ensteht |
| Ausfall | Vom Nutzer bemerkte Dienstminderung |
| Funktionelle Organisation Vorteile | Stabile Zuordnung der Mitarbeiter Keine Konflikte von Prioritäten |
| Funktionelle Organisation Nachteile | Keinde Identifikation mit dem Projekt schlechte Reaktion auf Probleme Motivationsproblem |
| Gantt Diagramm | Zeigt logische Abhängigkeit zwischen Paketen, welche nacheinander ausgeführt werden müssen und welche paralell abgearbeitet werden können |
| Garvin transzedente Qualitätsverständnis | entspricht der Sicht von Qualität, subjektive Erfahrung einer Person hinisichtlich der besonderen, einzigartigen Eigenschaften eines Produkts bzw. einer Dienstleistung |
| Garvin produktbezogene Qualitätsverständnis | die Qualität eines Produktes ergibt sich aus der Erfüllung von allgemein festgelegten Anforderungen |
| Garvin kundenbezogene Qualitätsverständnis | alle Anforderungen der Nutzer zur Realisierung des Produkts |
| Garvin fertigungsbezogene Qualitätsverständnis | Erfüllung von Zeichnungsangaben, Verinbarungen und Normen |
| Garvin wertorientierte Qualitätsverständnis | wenn ein Produkt hinsichtlich der realisierten Merkmale zu einem angemessenen Preis erworben werden kann (Kosten-Nutzen-Verhältnis) |
| Inkrementelle Entwicklung pro/contra | + Kern verändert sich nicht - überarbeitern vieler Module Der Reihe nach Ausbaustufen am Kernsystem hinzufügen, ausliefern und einsetzen |
| Iterative Entwicklung pro/contra | +Aufteilung der Arbeitsbelastung -Kernsystem Auslieferung dauert unter Umständen länger Großes Projekt in kleine Projekte gegliedert Entworfen -> Codiert -> Getestet -> Erprobt (Kreislauf) |
| Kohäsion | Verbindung von Methoden untereinander geschieht durch gemeinsame Klassenvariablen |
| Kopplung | Abhängigkeit zwischen Modulen |
| Kopplungen Daten | mehrere Module greifen auf einen Datenbestand zu |
| Kopplungen Datenstruktur | Modul übergibt anderem Modul eine zusammengesetzte Datenstrutkur Kopplung (Objekt) |
| Kopplungen Kontroll | wenn ein Modul ein anderes durch Übergabe eins Parameters steuert |
| Kopplungen Extern | Wenn Komponenten über globale Daten kommunizieren |
| Kosten Software Entwicklung | Personal |
| Kostenverteilung auf Wartungsfälle | perfektionierend: 45% adaptiv: 25% präventiv: 25% korrektiv: 5% |
| Lack of Cohesion | P ohne gemeinsame Klassenvariablen Q mit gemeinsamen Klassenvariablen LCOM = |P|-|Q| wenn P > Q, sonst 0 |
| Latenzzeit | Fehlerkosten steigen exponentiell an Zeitpunkt vom auftreten bis zum beheben des Fehlers |
| Legacy Systeme | Alte Systemkomponenten Erneuerung schlägt fehl weil keine Entwickler mehr für die jeweilige Sprache oder System darf nicht aufallen |
| Make | FLexibler |
| Buy | Günstiger kleineres Risiko ausgereifte Lösung Wartung und Portierung günstiger Zeitersparnis |
| Matrix Organisation Vorteile | große Flexibilität Zugriff auf Spezialisten leicht organisierbar auch für kleine Projekte jeder Mitarbeiter hat stabile Heimat im Unternehem |
| Matrix Organisation Nachteile | jeder Mitarbeiter min. 2 Vorgesetzte (Kompetenzkonflikte) hoher Kommunikationsaufwand schwerfällige und lang andauernde Entschieidungsfindung herausfordernde Leitungskontrolle |
| Modul | in sich abgeschlossen enthält Daten und Funktionen die von außen nur teilweise sichtbar sind |
| Organisationformen für Unternehmen | Funktionale Organisation Projekt Organisation Matrix Organisation |
| Performanz | Leistung der angewenden Software im Vergleich zur verwendeten Hardware |
| Planungsaspekte | Planung der: Aufgaben, Termine, Ressourcen |
| Product-Ownder | legt Produkteigenschaften fest testet Wirtschaftlichkeit Feauters anhand ihres Marktwertes analysieren |
| Projekttypen (2) | Entwicklungsprojekt -man entwickelt um etwas anzubieten Auftragsprojekt - Entwicklung nach Wünschen eines Auftraggebers |
| Prozessqualität | Qualität des Vorgehens |
| Prüfling | Ausschnitt aus Quellprogramm der direkt oder indirekt die Umgebung enthält |
| Prüfresultate (4) | Richtig Positiv = Test erkennt Fehler Richtig Negativ = Test erkennt das keine Fehler im Code sind Falsch Positiv = Test erkennt Fehler die nicht vorhanden sind Falsch Negativ = Test erkennt Fehler nicht |
| Qualitätsansätze Fokus auf verlässliche Systeme (Dependability u. Security) | Safety Reliability Availability Confdentaility Integrity Maintability |
| Qualitätssicherung | analytisch: entstandenes Programm überprüfen konsturktive SE: Ingenieurprinzipen von Anfang an verfolgen |
| Reverse Engineering | Ein Prozess der das betrachtete System analysiert, um seine Komponenten und Beziehungen zu identifzieren |
| Review (Ablauf) | Moderator Notar Gutachter Autor |
| Restructuring/Refactoring | Code neu strukurieren ohne Semantik oder Interaktion zu ändern |
| Risiko | Problem das nicht eingetreten ist und das Projekt und dessen Ziele gefährden kann |
| Riskiomanagement | Identifikation von Risiken Analyse und Bewertung Planung von Gegenmaßnahmen Verfolgung von Risiken und der gewählten Gegemaßnahmen |
| Safety | Kann das System nach außen hin gefählich sein? (Software als Akteur) |
| Scrum-Charakteristik (agiler Prozess) | Selbst-organisiertes Team Produkt schreitet in Serien/Abschnitten von monatlichen Sprints fort keine spezifische Entwicklungsmethode generative Regeln um ein agiles Umfeld für die Auslierferung zu schaffen |
| Product-Backlog | Anforderungen als Listeneintrag |
| Scrum-Master | repräsentiert das Management gegenüber dem Projekt Verantwortlich für die Einhaltung von Scrum Werten und Technik stellt produktiviät und funkitonaliät des Teams sicher unterstützt die Zusammenarbeit zwischen Rollen und Funktionen schützt das Team vor äußeren Störungen |
| Securtiy (Datensicherheit, Integriät, Availability) | Sicherheit vor Angriffe von Außerhalb auf die Software |
| Softwarekrise | 1960er Jahre Kosten für Software > Hardware -> erste gescheitereten Software Projekte |
| Softwareentwickler | Analytiker (erhebt die Anforderungen) Programmierer (Feinentwurf, Kodierung, Test) Software Architekt (entwickelt Struktur, leitet und überwacht) Wartungs Ingenieur (Entwickler in der Wartung) |
| Softwareprojekt (Eigenschaften) | Temporär Startdatum, Endatum Budget, Ziele, Ablaufplan Ziele und Auflagen |
| Sprint Elemente | entwerfen codieren testen Dauer 2-4 Wochen |
| Retrospektive | nach jedem Sprint 15-30min bespricht was gut und was schlecht war ganze Team nimmt teil |
| Stand Up Scrum Meeting | Täglich 15 min. Nicht zur Problemlösung Alle sind eingeladen Teammitglieder, ScrumMaster und Product-Owner dürfen reden im stehen Hilft andere überflüssige Meetings zu vermeiden |
| Stand Up Scrum Meeting Fragen die jeder beantworet | Was hast du gestern getan? Was wirst du heute tun? Welche HIndernisse sind im Weg? |
| Lift off Meeting | Alignment purpose and context |
| Software Architektur | Ist gut, wenn die funktionalen und nicht funktionalen Anforderungen erfüllt werden können |
| Software-Architekturmodelle (Drei-Schichten-Modell) Vorteile? | Präsentationsschicht Andwendungschicht Datenhaltungsschicht Vorteile: lose Kopplung Änderung in einer Schicht wirken sich meist nur lokal aus |
| Präsentationsschicht | realisiert Bedienoberfläche kommuniziert mit der Anwednugnsschicht |
| Anwendungsschicht | beinhaltet alle Komponenten, die die Funkitonalität realisieren |
| Datenhaltungsschicht | dauerhafte Speicherung meist in Datenbank |
| Stake Holder | jeder der ein Interesse am Produkt hat Endanwender Kunde Entwickler Betreiber |
| Software altert | unkundliche Behandlung sinkende Performanz |
| automatisierte Tests | häufige Ausführung Regressionsfehler |
| Explorative Tests | manuell kreativ Neue Fehler |
| Blackboxtest (Funktionstest) | ohne internes Wissen soll die Funktion getestet werden |
| Whiteboxtest (Strukturtest) | Zugriff auf die innere Struktur, des zu prüfenden Quellcodes Versuch: alle Zustände im Programm zu durchlaufen |
| Glassboxtest | Befehlsüberdeckung Zweigüberdeckung Termüberdeckung Pfadüberdeckung |
| Test-Driven Development | 1. kein Produktioncode bevor du einen Fehlgeschlagenen JUnit Test hast 2. nur so viel Code für den Test, für das nichtbestehen nötig 3. nur so viel Code wie für den Testfall und bestehen hinreichend |
| Epic | sehr große User-Story, zu groß für eine Arbeitseinheit |
| Theme | eine Ansammlung von User Stories (passen thematisch zusammen) |
| Organisationformen für Teams | Ein-Personen Team Gruppen aus 2 Personen Pair Programming Anarchische Team Demokratisches Team Hierachisches Team Chief-Programmer-Team |
| Demokratisches/Kooperativ Team Vorteil/Nachteil | Vorgesetzter bezieht Mitarbeiter in Betriebsgeschein mit ein. Vorteile: hohe Motivation, Förderung der Leistungsfähigkeit, höhere Selbständigkeit, entlastung der Vorgesetzten Nachteile: Entscheidungsgeschwindigkeit verlangsamt, qualifizierung der Mitarbeiter erforderlich, ausreichende Information muss vorlegen |
| Hierachischer/Autoritärer Führungsstil Vorteil/Nachteil | Vorgesetzer gibt Anweisungen, Aufgaben und Anordnungen weiter, ohne seine Untergebenen in die Entscheidung einzubeziehen Vorteil: hohe Entscheidungsgeschwindigkeit, Übersichtlichkeit der Kompetenzen, gute Kontrolle Nachteile: mangelnde motivation, Einschränkung der persönlichen Freiheit, geringe Selbstständigkeit |
| Was ist ein Scrum-Projekt? | Vorgehensmodell des Projekt- und Produktmanagement Besteht aus: Langfristiger Plan (Product Backlog), Detailplan (Sprint Backlog) und Sprints |
| Wie ist ein Scrum-Projekt organisiert? | Product Owner Entwicklungsteam Scrum Master |
Quer criar seus próprios Flashcards gratuitos com GoConqr? Saiba mais.