CoboCards App FAQ & Wünsche Feedback
Sprache: Deutsch Sprache
Kostenlos registrieren  Login

Zu dieser Karteikarte gibt es einen kompletten Satz an Karteikarten. Kostenlos!

Alle Oberthemen / Informatik / Softwaretechnik / Softwaretechnik + Softwarequalitätssicherung
13
Welche Prozessmodelle gibt es?
Prozessmodelle machen Aussagen über
- Organisation und Rollenverteilung
- Struktur der Dokumente
- Verfahren für die Anforderungserhebung
- das Vorgehensmodell
- Phasen, Meilsensteine, Prüfkriterien
- Notationen und Sprachen
- Werkzeuge

V-Modell
- Teil des Entwicklungsstandards für IT Systeme des Bundes (1992)
- erweiterte Version: V- Modell XT (2004) XT=Extreme Tailoring
- Meilenstein am Ende jedes Projektabschnitts
- unterstützt verschiedene Entwicklungsarten (inkrementell, komponentenbasiert, agil)
- trennt zwischen Auftraggeber- und Auftragnehmerprojekten
- Jedes Modell definiert Vorgehensbausteine und Projektdurchführungsstrategien
- Projektdurchführungsstrategien ordnen Entscheidungspunkte an
- Produkte müssen beim Erreichen eines Entscheidungspunktes fertig sein
- Vorgehensbaustein fasst Rollen, Produkte und Aktivitäten zusammen, die notwendig zur Lösung der Projektaufgabe sind
- Projekt muss aus mind. 4 Vorgehensbausteinen bestehen (Projektmanagement, Qualitätssicherung, Problem- und Änderungsmanagement, Konfigurationsmanagement)
- ggf. mehr Bausteine durch Tailoring
- Produkt wird durch genau eine Aktivität fertiggestellt
- Produkte hängen voneinander ab
- Rollen sind für Produkte verantwortlich und wirken an diesen mit
- wichtig zu merken: Auf jeder Ebene des Vorgehensmodells gibt es ensprechende Tests (Analyse->Abnahmetest, Grobentwurf->Systemtest, Feinentwurf->Integrationstest, Implementierung->Modultest)
- produziert Overhead bei kleinen Projekten

Unified Process
- auf Objektorientierung abgestimmte Methode durch Jacobsen (1998)
- basiert auf Use Cases
- iterativ: Prototypen in frühen Iterationen
- architekturzentriert
- Besteht aus 4 Phasen (Inception: Verstehen der Anforderungen, Risikobewertung, Use-Case Modellierung, 1. Fassung der Architektur/des Projektplans, Elaboration: Identifkation fehlender Anforderungen, grundlegende Architekturentscheidungen, Construction: Implementierung, Integration + Test, Ergebnis: Betaversion des Systems, Transition: Verbesserung des Systems bis es stabil läuft, Vervollständigung des Systems)
- Arbeitsabläufe, die in unterschiedlicher Intensität während jeder Phase durchgeführt werden: Requirements, Analysis, Design, Implementation, Test (ggf. mehr durch Tailoring, es kommen dann businessorientiertere Arbeitsabläufe hinzu)
- in jeder Phase gibt es mehrere Iterationen
- RUP ist die Ausprägung des UP zu vollwertigem Prozessmodell und wird durch IBM vermarketet
- Arbeitsabläufe werden hier durch UML Aktivitätsdiagramme visualisiert
- Vorteile: gute Dokumentation, guter Support
- Nachteile: geringe Tailoringmöglichkeiten, Unternehmensprozess muss angepasst werden, wenn RUP sich ändert

Agile Methoden

- Idee: Entbürokratisierung des Prozesses
- beruht auf Agile Manifesto (2001)
- Grundprinzipien: Förderung von Kommunikation/Kollaborisation, Zusammenarbeit mit dem Kunden
- iterativ
- kleine Gruppen arbeiten in großem Raum
- keine großartige Dokumentation
- Kunde immer präsent
- Common Code Ownership: Jedem gehört der Code (d.h. jeder kennt den Code und darf auch selbst alles ändern)
- Kurze Release Zyklen
- Paarprogrammierung
- Standup Meeting (täglich 15 min. im Stehen)
- Testgetriebene Entwicklung (Tests werden vor Methoden geschrieben)
- gemeinsame Strukturverbesserung vor dem Schreiben neuer Methoden
- für große Projekte ungeeignet

Cleanroom Development
- Grundidee: Entwickle Software so, dass sie gleich korrekt ist (frühe Fehlervermeidung)
- großes Projekt wird durch Serie kleiner Projekte ersetzt
- 5-8 Entwickler pro kleinem Projekt
- Anforderungsspezifikation muss hoch formal sein
- Entwickler dürfen Code nicht kompilieren, um ihn zu testen
- Komponenten werden nicht einzeln, sondern zusammen getestet (statistischer Test mit Zufallsdaten, wobei die Soll-Resultate nur vage bekannt sind)
- Fehler werden nur in geringem Umfang toleriert. Zu viele Fehler-->Neuimplementierung
- Vorteil: Systeme sind ungewöhnlich fehlerarm
- Nachteil: Hohe Anforderungen an Entwickler, Systeme mit unklarer Spezifikation können mit diesem Prozess nicht entwickelt werden
Neuer Kommentar
Karteninfo:
Autor: ChristianK
Oberthema: Informatik
Thema: Softwaretechnik
Schule / Uni: RWTH Aachen
Ort: Aachen
Veröffentlicht: 24.04.2010

Abbrechen
E-Mail

Passwort

Login    

Passwort vergessen?
Deutsch  English