CREATE TEST

ERASED TEST, YOU MAY BE INTERESTED ON Management von IT-Projekten

COMMENTS	STATISTICS	RECORDS

TAKE THE TEST

Title of test: Management von IT-Projekten Description: Management von IT-Projekten Author: PE Other tests from this author Creation Date: 15/10/2024 Category: Others Number of questions: 93

Share the Test:

New Comment

No comments about this test.

Content:

Welche der nachfolgenden Aussagen über PRINCE2 ist bzw. sind richtig? Kernelemente von PRINCE2 sind Managementaktivitäten und Managementartefakte. In PRINCE2 werden detailliert Aktivitäten beschrieben, mit denen Softwaresysteme konstruiert werden PRINCE2 ist ein Modell für das IT-Projektmanagement, das sich insbesondere für kleine Projekte eignet. Welche der nachfolgenden Aussagen zu Managementebenen in PRINCE2 ist bzw. sind richtig? Der Projektleiter wird der Ebene 3 zugeordnet und ist für fast alle Leitungsaufgaben zuständig. Personen der Ebene 1 sind nicht Teil des Projektteams Ebene 2 wird durch einen Lenkungsausschuss gebildet, der vom Hauptnutzer geleitet wird Projektergebnisse, die nicht nur Managementartefakte sondern die eigentlichen direkte Projektergebnisse sind, werden in Ebene 4 erstellt. In dem Prozess „Initiieren eines Projektes“ in PRINCE2 wird ein erster Projektplan erstellt werden Erkenntnisse gewonnen, auf deren Basis der Lenkungsausschuss entscheidet ob das Projekt weitergeführt werden soll. wird das Projektleitdokument erstellt. Der Prozess „Steuern einer Projektphase“ in PRINCE2 enthält Aktivitäten zum Management von Arbeitspaketen und wird maßgeblich vom Lenkungsausschuss durchgeführt. wird typischer Weise genau 1x während eines Projektes durchgeführt. enthält gezielte Aktivitäten, um mögliche Probleme und Fehlentwicklungen im Projekt zu erkennen. Das Pragmatisches IT-Projektmanagement (PITPM) besteht in seiner Grundstruktur aus den folgenden fünf einzelnen Phasen, die dem Ablauf eines typischen Softwareprojektes folgen: Vorbereitung, Planung, Implementierung, Wartung und Abschluss. enthält Kontrollpunkte, mit denen der Übergang von einer Phase zur nächsten entschieden wird. ist ein Modell für das Management von IT-Projekten, das besonders für sehr große Projekte geeignet ist. Welche der nachfolgenden Aussagen über die Projektphasen in PITPM ist bzw. sind richtig? Eine erste Risikoabschätzung erfolgt bereits in der Vorbereitungsphase. In der Implementierungsphase werden alle Aktivitäten durchgeführt um das System zu konstruieren. Das Projekt endet mit dem Kontrollpunkt „Projekt beendet“ nach der Abschlussphase. Die Konfiguration eines IT-Projekts in PITPM umfasst die konkrete Projektorganisation und die Projektmanagementplanung enthält gezielte Handlungs-, Eskalationsvorgaben, damit Teams auch in Ausnahmesituationen gezielt handeln kann. wird durch den Projektleiter erstellt und legt mit dem Projektmanagementplan fest, wie das PITPM-Modell projektspezifisch angepasst wird. Die Qualitätsplanung in PITPM .. enthält zwar Vorgaben für das konstruktive Qualitätsmanagement, jedoch nicht für das analytische Qualitätsmanagement. legt einen detaillierten Testplan für das Projekt fest. gibt den Rahmen für die Konzeption und Durchführung von Softwaretests innerhalb des Projekts. Welche der nachfolgenden Aussagen über die Steuerung eines Projekts in PITPM ist bzw. sind richtig? Um das Projektbudget einzuhalten, sollte während der Durchführung eines Projekts kein Change Request ausgelöst werden. Der Projektleiter führt insbesondere in der Durchführungsphase Aktivitäten zur Projektsteuerung durch. Eine wichtige Aufgabe der Projektsteuerung ist die Kostenkontrolle, für die in PITPM die Earned-Value-Technik vorgeschlagen wird. Welche der nachfolgenden Aussagen zur Aktivität Steuerung des Projektteams in PITPM ist bzw. sind richtig? Der Projektleiter vergibt konkrete Aufgaben und Zuständigkeiten und dokumentiert dies im Projektplan. Die Bewertung der Leistung des eines Teammitglieds erfolgt immer durch den direkten Vorgesetzten und niemals direkt durch den Projektleiter. Der Projektleiter plant das Projektteam ausschließlich auf Basis des aktuell verfügbaren Personals. Die tatsächlich benötigten Kompetenzen spielen dabei eine untergeordnete Rolle. Das V-Modell XT ... ermöglicht auf Basis von definierten Projekttypen die Auswahl konkreter Vorgehensbausteine. ist ein Softwareprozessmodell, das verbindlich für öffentliche IT-Projekte in der Bundesverwaltung vorgeschrieben ist. bietet mit seinen 4 Hauptelementen ein umfassendes Rahmenwerk zur Konstruktion eigener Softwareprozessmodelle. Entscheidungspunkte im V-Modell XT... sind in Art und Anzahl nur durch den Projekttypen bestimmt. sind Grundlage für die Feststellung, ob eine neue Phase im Projekt erreicht wurde. legen die Reihenfolge der Projektdurchführungsstrategie fest. Die Referenzen im V-Modell XT ... liefern eine Definition der Aktivitäten und Rollen im V-Modell XT, jedoch nicht der zu erstellenden und eingesetzten Ergebnisse. liefern unter Anderem eine Definition der Aktivitäten und Rollen im V-Modell XT und der zu erstellenden und eingesetzten Ergebnisse. sind ausschließlich nur im Rahmen öffentlicher Projekte anzuwenden, jedoch nicht bei der Definition eigener Softwareprozessmodelle. Der Rational Unified Process (RUP) ... beginnt mit der Phase „Inception“ und endet mit der Phase „Transition“. gliedert den Softwareprozess in fünf Phasen. darf ausschließlich nur im industriellen Umfeld eingesetzt werden. Mit der Unterteilung des Softwareprozesses durch den RUP in verschiedene Phasen .. werden die einzelnen Software-Engineering-Kernaktivitäten schwerpunktmäßig auf den Softwareprozess verteilt, jedoch nicht genau abgegrenzt. werden die einzelnen Software-Engineering-Kernaktivitäten genau abgegrenzt. erhält der Softwareprojekt eine grobe Struktur. Im Rational Unified Process .. wird das Prozessparadigma „evolutionäre Entwicklung“ durch die mehrfache Ausführung der einzelnen Phasen ermöglicht. wird in allen Phasen implementiert, jedoch hauptsächlich in den Phasen Inception und Construction beschränkt sich das Requirements Engineering auf die ersten beiden Phasen. Das Prozessmodell Rahmenwerk Scrum ... unterstützt im Vergleich zum RUP das Prozessparadigma „evolutionäre Entwicklung“ besonders auf intensiv. macht strenge Vorgaben für Aktivitäten, deren Reihenfolge und die dabei erzeugten Ergebnisse. wurde anders als RUP und V-Modell XT nicht gezielt für das Software Engineering entwickelt. Die Rollen in Scrum ... umfassen auch den Scrum Master, der für das reibungslose Arbeiten des Teams zuständig ist. sind Product Manager, Scrum Master und Team. umfassen auch den Product Manager, der in Scrum für das Requirements Engineering zuständig ist. Der allgemeine Ablauf eines Scrum-Projekts ... besteht hauptsächlich aus der Durchführung sogenannter Sprints, der Zyklen im Scrum. beginnt mit der initialen Erstellung des Product Backlog. kann durch den Scrum Master nach Belieben verändert und variiert werden. Die Durchführung eines Sprints im Scrum ... umfasst für jeden Sprint die gleichen Phasen. endet mit einer gemeinsamen Reflektion aller Beteiligten ob und wie die Zusammenarbeit im Projekt verbessert werden kann. ist die Durchführung der Phasen in folgender Reihenfolge: Planning, Durchführung, Retrospektive, Review. Prozessparadigmen werden durch Softwareprozessmodell-Rahmenwerke um konkrete Rollen und Aktivitäten verfeinert. sind beispielsweise das Wasserfallmodell und das V-Modell XT. sind grobe, allgemeine Vorgehensmodelle die zu Softwareprozessmodellen das Grundprinzip und Rollen, jedoch keine Aktivitäten vorgeben. Softwareprozessmodell-Rahmenwerke ... dienen als Vorlage bei der Erstellung eines organisationsspezifischen Softwareprozessmodells. finden in der Praxis fast keine Anwendung. sind beispielsweise das V-Modell XT, Rational Unified Process und Scrum. Ein Softwareprozess ... wird nach den Vorgaben und Rahmenbedingungen durchgeführt, die das individuellen Softwareprozessmodell vorgeben. gibt vor, wie Softwareprojekte durchgeführt werden müssen. ist ein in Durchführung befindliches konkretes Softwareprojekt. Das Wasserfallmodell ... ermöglicht nicht den Rücksprung in die Vorgängerphase zur aktuellen Phase. teilt den Softwareprozess in einzelne Phasen ein, die den Kernaktivitäten im Software Engineering folgen. teilt den Softwareprozess in einzelne Phasen ein, die immer mehrfach durchlaufen werden. Der Übergang von einer Phase in die nächste ist im Wasserfallmodell ... jederzeit möglich, sobald es der Projektleiter beschließt. nur zwischen benachbarten Phasen möglich. erst möglich, sobald alle Aktivitäten einer Phase vollständig abgeschlossen und die Ergebnisse ausführlich dokumentiert und getestet wurden. Durch die strikte Einhaltung der Vorgaben des Wasserfallmodells ... kann sich das Projekt zu jedem Zeitpunkt nur in genau einer Phase befinden. kann mit der Implementierung des Systems bereits begonnen werden, sobald der Programmentwurf zu 80 % fertig ist. kann mit der Implementierung des Systems nicht begonnen werden, auch wenn der Programmentwurf bereits zu 80 % fertig ist. Im V-Modell ... werden den konstruktiven Phasen jeweils eine konkrete Teststufe auf der gleichen Detaillierungsebene zugeordnet, um den Aspekt der Qualitätssicherung im Vergleich zum Wasserfallmodell stärker zu betonen. werden die konstruktiven Phasen und korrespondierenden prüfenden Phasen abwechselnd durchgeführt. werden die Phasen wie im Wasserfallmodell streng nacheinander abgearbeitet. Das Prozessparadigma „evolutionäre Entwicklung“ ... strukturiert den Softwareprozess nach den Software-Engineering-Kernaktivtäten. hat als Grundprinzip die Erstellung eines Softwaresystems in Form von mehreren, sich kontinuierlich wiederholenden Zyklen. legt kein Ziel für einen Zyklus fest. Für jeden einzelnen Zyklus wird das Ziel immer wieder neu bestimmt. Mit dem Zyklus als Grundprinzip der evolutionären Entwicklung ... kann ein Softwareprojekt auf Basis einer vollständigen Spezifikation vollständig durchgeplant werden. kann das Projektteam auf neue Anforderungen kurzfristig reagieren. werden die Software-Engineering-Kernaktivitäten kleinteilig miteinander verzahnt. Im Vergleich zum Wasserfallmodells ist bei der evolutionären Entwicklung ... wird bereits sehr früh im Softwareprozess eine erste Version der Software erstellt. die Phase in der die Architekturbeschreibung erstellt wird identisch. die Unsicherheit über den geplanten Funktionsumfang zu Beginn des Projektes größer, da vor Beginn der Implementierung kein detailliertes Spezifikationsdokument erstellt wird. Die Aufteilung von Teammitglieder in Rollen ... ermöglicht Expertenbildung verhindert Spezialisierung. erleichtert das Zusammenarbeiten in großen Teams. Eine Rolle ... die an eine Person im Projekt bereits vergeben ist, kann nicht an eine weitere Person vergeben werden. kann durch eine Person ausgeführt werden, die gleichzeitig auch eine oder mehrere andere Rollen inne hat. ist gekennzeichnet durch ihren Namen und spezifische Zielsetzungen, jedoch nicht durch spezifische Aufgaben. Zwischen verschiedenen Rollen ... gibt es automatisch Zielkonflikte, die zu Beginn des Projekts ausgehandelt werden müssen. darf es keine Konflikte geben. Dafür muss der Projektleiter sorgen. gibt es automatisch Zielkonflikte, die kontinuierlich über die gesamte Projektlaufzeit ausgehandelt werden müssen. Rollen mit übergreifenden Einfluss ... sind typische Managementrollen, sie erstellen Vorgaben und prüfen deren Einhaltung. sind begleitend zu allen anderen Rollen aktiv. gibt es in einem Softwareprojekt nicht. Rollen die aktiv an der Entwicklung beteiligt sind ... sind begrenzt auf Architekt und Entwickler. führen konstruktive Aktivitäten aus oder deren Aktivitäten hängen unmittelbar mit konkreten erstellen Artefakten zusammen. sind unter anderem Architekt und Entwickler. Rollen die hauptsächlich für Integration und Betrieb verantwortlich sind ... sind Integrator und Systemtechniker. haben immer die gleichen Projekt- und Qualitätsmanager wie die konstruktiven Rollen. sind in der Regel in anderen Abteilungen als die konstruktiven Rollen organisiert. Der Tester ... prüft die Ergebnisse des Entwicklers. erhält seine Vorgaben direkt vom Qualitätsmanager. arbeitet dem Entwickler zu. Der Architekt ... verarbeitet die Ergebnisse des Requirements Engineer. gestaltet und überwacht die Architektur, die von dem Entwickler geprüft wird. gestaltet und überwacht die Architektur in einem Softwareprojekt. Der Projektmanager... erstellt und prüft die organisatorischen Vorgaben in einem Softwareprojekt. erstellt und prüft die technischen Vorgaben in einem Softwareprojekt. ist für die erfolgreiche Durchführung des Projekts verantwortlich. Der Entwickler... erarbeitet auf Basis von Spezifikation und Architektur den Programmcode, der nur vom Qualitätsmanager getestet wird. erzeugt den Programmcode, dabei wird er bzw. das von ihm erstellte Ergebnis von Architekt, Projektmanager, Qualitätsmanager und Tester geprüft bzw. getestet. ist maßgeblich mit dem Architekten an der Erstellung der Architekturbeschreibung beteiligt. Die Phasen des Softwarelebenszyklus ... markieren die aktuelle Situation eines Softwaresystems bezogen auf dem gesamten Lebenszyklus. können immer genau voneinander abgegrenzt werden. werden für die mittel- und langfristige Projektplanung genutzt. Die Reihenfolge der Phasen im Softwarelebenszyklus lautet: Entwicklung, Planung, Wartung, Betrieb und Abschaltung Planung, Entwicklung, Betrieb, Wartung und Abschaltung Planung, Betrieb, Entwicklung , Wartung und Abschaltung. In der Phase Planung ... werden alle Arbeitspakte des gesamten Projekts detailliert durchgeplant. wird entschieden ob ein System erstellt oder gekauft wird. werden alle Anforderungen an das neue System ermittelt. Der Bedarf für ein neues Softwaresystem ... entsteht durch ein sich ändernde fachliche Anforderungen. kann systematisch immer für die kommenden fünf Jahre geplant werden. entsteht wenn Altsysteme abgelöst werden müssen, weil es z. B. kein Know-how mehr gibt um diese zu warten und weiterzuentwickeln. Die Phase Entwicklung ... ist besonders stark ausgeprägt falls ein firmenspezifisches System vollständig neu erstellt werden soll. entspricht dem Zeitraum, in dem das System konstruiert wird. ist geprägt durch die Kernaktivitäten im Software Engineering. In der Phase Betrieb ... wird das System über seine technischen Schnittstellen in die Anwendungslandschaft integriert. werden umfassende Maßnahmen zur Qualitätssicherung durchgeführt, bevor das System in die Ausführungsumgebung übernommen wird. ist das System in Geschäftsprozesse der Organisation eingebunden und muss daher für die Nutzer verfügbar sein. Bevor eine Anwendung in Betrieb genommen werden kann,... muss eine entsprechende Ausführungsumgebung bereitgestellt werden, in der die Anwendung installiert wird. muss sie in die typischen Elemente der Ausführungsumgebung wie zum Beispiel Hardwaresysteme, Softwaresysteme, Datennetze und Sicherheitssysteme integriert werden. muss der gesamte Programmcode der Anwendung vollständig nochmal auf Fehler und Sicherheitslücken durchsucht werden. Wenn eine Anwendung einmal in Betrieb genommen wurde, ... muss ein zuverlässiger und stabiler Einsatz gewährleistet werden. dürfen nur noch minimal Änderungen an ihr durchgeführt werden. muss sie nur noch sporadisch, jedoch nicht kontinuierlich technisch überwacht werden. Bei Änderungen einer bestehenden Anwendung ... darf der Programmcode eines sich bereits in Betrieb befindlichen Systems nicht geändert werden. wird mit Releaseplänen die Arbeit der daran beteiligten Anwendungen koordiniert. wird immer durch die Fachabteilungen genau festgelegt, wann die neue Version verfügbar sein muss. Bevor ein System abgeschaltet werden kann ... muss jede einzelne, aktiv genutzte technische Schnittstelle des Altsystems entweder durch ein neues oder bereits bestehendes Alternativsystem abgedeckt werden. muss der Betriebsrat immer seine Zustimmung dazu gegeben haben. müssen alle Abhängigkeiten der abzuschaltenden Anwendung identifiziert und aufgelöst werden. Durch welchen bzw. welche der nachfolgenden Faktoren wird die Komplexität von industriellen Softwaresystemen bestimmt? Ein Softwaresystem besteht aus vielen verschiedenen Komponenten und Teilsystemen. Ein Softwaresystem muss möglichst vielfältige Funktionen unterstützten und auf vielen verschiedenen Geräten funktionieren. Ein Softwaresystem ist über technische Schnittstellen mit vielen anderen Softwaresystemen verbunden und wird von vielen Anwendern eingesetzt. Zusätzlich zur Bereitstellung von fachlichen Funktionen sollen industrielle Softwaresysteme ... für den Fall, dass sie nicht so bedient werden wie ursprünglich vorgesehen, keine unkontrollierten Fehler verursachen. in jedem Fall über einen Zeitraum von 10 Jahren oder länger dauerhaft einsetzbar sein und sich robust verhalten. die für das System vorgesehenen Nutzer- und Datenmengen unterstützen, so dass bei Bedarf mehrere hundert oder tausend Nutzer gleichzeitig mit dem System arbeiten können. Mit dem Begriff „Softwaretechnik“ ... wird eine 145 Jahre alte Ingenieursdisziplin bezeichnet. wird die englische Bezeichnung „Software Engineering“ in die deutsche Sprache übersetzt. wird sowohl die Erstellung als auch die Anwendung von umfangreichen Softwaresystemen bezeichnet. Risiken, die zum Abbruch von Softwareprojekten führen können ... können sowohl vor der Fertigstellung der Software als auch nach der Auslieferung von Software identifiziert werden. sind beispielsweise die Ablehnung durch die Anwender oder die falsche Umsetzung zentraler Fachfunktionen. sind immer auf technische Probleme zurückzuführen. Nach der erfolgreichen Auslieferung von Softwaresystemen ... besteht das Risiko, dass durch Änderungen im System Fehler erzeugt werden, die es bei der Auslieferung nicht gab. können Wartungsarbeiten immer kostengünstig durchgeführt werden. gibt es keine Risiken mehr. Der Erstellungsprozess von betrieblichen Informationssystemen ... kann in der Regel exakt geplant werden. ist durch wirtschaftliche und technologische Unsicherheiten gekennzeichnet. ist ein stark erkenntnisgetriebener Prozess. Die Anforderungen an das zu erstellende Softwaresystem ... verändern sich typischerweise im Verlauf eines Softwareprojekts. bilden den Ausgangspunkt für alle wesentlichen Aktivitäten im Software Engineering. Das bedeutet, sie müssen zu Beginn eines Projektes vollständig ermittelt werden. bilden den Ausgangspunkt für alle wesentlichen Aktivitäten im Software Engineering, können jedoch zu Beginn eines Projektes nicht vollständig ermittelt werden. Bei der Erstellung von Softwaresystemen ... führt ein vernachlässigtes Kommunikationsmanagement in Projekten mit vielen verschiedenen beteiligten Personen zu Konflikten. ist fehlendes Fachwissen auf der Seite der Softwareentwickler eine mögliche Ursache für gescheiterte Softwareprojekte. müssen sich die Entwickler ausschließlich auf die eingesetzten Technologien konzentrieren, denn neue Technologien haben für den Anwender immer den größten Nutzen. Zu den Herausforderungen im Software Engineering ... zählt die technologische Ungewissheit nur bedingt, denn die Softwareentwickler konzentrieren sich ausschließlich auf technologische Aspekte innerhalb des Projektes. zählt die Erstellung und Aufrechterhaltung der Kooperationsbereitschaft der Stakeholder. zählt der Umgang mit bzw. das Aushalten von wirtschaftlicher Ungewissheit, denn erst am Ende eines Projekts können die Kosten genau beziffert werden. Bitte markieren Sie die richtige bzw. richtigen Aussagen zu Zielkonflikten im Software Engineering. Wenn nach Beginn eines Projektes alle Anforderungen an das System bekannt sind, ändern sich die Zielgrößen nicht mehr. Der Fokus auf eine bestimmte Zielgröße hat Auswirkungen auf die Erreichung der anderen Zielgrößen. Kundenzufriedenheit ist ein wichtiges Ziel, jedoch im Vergleich zu den Zielen Kosten, Termin und Qualität nicht das wichtigste Ziel. Das agile Manifest .. gilt als Gegenentwurf zu einer starken Ausprägung von organisatorischen Regeln und Vorgaben klassischer Prozessmodelle. wurde von erfahrenen Praktikern veröffentlicht und stellt ausführliche definierte Prozessmodelle in den Vordergrund. stellt das eigentliche Ziel des Projektes über die strikte Einhaltung organisatorischer Regeln. Nach dem Wortlaut des agilen Manifests ... sollte in Softwareprojekten nur noch wenig dokumentiert werden. wird die Interaktion zwischen Personen höher eingeschätzt als Prozesse und Werkzeuge. dürfen Pläne nicht niemals strikt befolgt werden. Welche der nachfolgenden Aussagen zu den Kernaussagen des agilen Manifest ist bzw. sind richtig? Die direkte Zusammenarbeit mit dem Kunden ist sehr wichtig, jedoch darf er bei der inhaltlichen Gestaltung nicht aktiv mit eingebunden werden. Ausführliche Dokumentationen helfen nur, falls das System gut funktioniert. Mit einem zu starken Fokus auf Dokumentation werden Ressourcen gebunden, die ggf. bei der Systemerstellung fehlen. Zwar helfen Werkzeuge und Prozesse, jedoch wird der Projekterfolg durch eine gute die Zusammenarbeit von Personen bestimmt. Bitte markieren Sie von den nachfolgenden die Aussagen diejenige bzw. diejenigen, die einen agilen Softwareprozess charakterisieren. Entwickler und Fachexperten arbeiten nur in frühen Projektphasen zusammen. Der Fortschritt des Projekts wird anhand der funktionieren Software gemessen. Übermittlung von Informationen innerhalb des Entwicklungsteams erfolgt wenn möglich immer in einem persönlichen Gespräch. Im Vergleich zum Wasserfallmodell ... liegt der Fokus der Führung von IT-Projekten auf einem funktionierendem Produkt, und nicht auf der Einhaltung definierter Projektphasen. steht bei der agilen Softwareentwicklung die enge Zusammenarbeit der Projektbeteiligten im Vordergrund. liegt der Fokus der agilen Softwareentwicklung in detailliert geplanter Zusammenarbeit zwischen Entwickler und Fachexperten. Dem Value-Based Software Engineering liegt bzw. liegen welche der nachfolgenden Dinge zu Grunde? Bei Entscheidungen gezielt die Schaffung von Werten mit zu berücksichtigen. Eine konsequente Orientierung an dem maximal erzielbaren Nutzen nur für den Auftraggeber des Projekts. Eine konsequente Orientierung an dem maximal erzielbaren Nutzen für die Stakeholder eines Projekts. Das Value-Based Software Engineering zielt darauf ab ... die Schaffung von Werten gegenüber den entstehenden Kosten immer höher zu priorisieren. Anforderungen an ein System nicht als neutral zu behandeln, sondern die in den Vordergrund zu rücken, welche die größten Wert schaffen. neben verbrauchten Kosten und Zeit auch die geschaffenen Werte im Projektcontrolling mit zu berücksichtigen. Value-Based Software Engineering ... ist eine Sammlung von Techniken und Prinzipien zur Einhaltung zum Projektcontrolling. ist zwar kein vollständiges Vorgehensmodell, beinhaltet aber Techniken um die geschaffenen Werte bei Projektenscheidungen gezielt zu berücksichtigen. ist eine neue Methode, die gezielte Aktivitäten zur Erstellung von System beschreibt. Welches bzw. welche nachfolgenden zählen zu den Hauptelementen des Value-Based Software Engineering? ein kontinuierliches Management von Risiken und Alternativen. die Ausarbeitung und Schlichtung der Interessen der Stakeholder. die Business-Case-Analyse. Die wertebasierte Projektüberwachung und -steuerung im Value-Based Software Engineering .. prüft mit der Business-Case-Analyse der Verhältnis von Ausgaben zu den bereits erzielten Werten. berücksichtigt die tatsächlich erstellten Ergebnisse. legt den Fokus auf bereits verwende Ressourcen und den Bearbeitungsstand der Arbeitspakete. Das Kanban Board ... enthält Arbeitspakete oder Aufgaben, die sich im Verlauf der Abarbeitung von rechts nach links durch verschiedene Spalten des Boards bewegen. kann projektspezifisch angepasst werden, wobei Anzahl der Spalten und Beschriftung der Spalten grundsätzlich frei gewählt werden können. ist eine Technik zur Steuerung von Produktionsprozessen und stammt ursprünglich aus der Fertigungsindustrie. Welche der nachfolgenden Aussagen zum Kanban Board ist bzw. sind richtig? Wichtig beim Einsatz des Kanban Board ist die persönliche Zuweisung der Arbeitspakete an die Teammitglieder durch den Projektleiter. Mit einem Kanban Board kann die aktuelle Projektsituation für alle Beteiligten einfach und übersichtlich dargestellt werden. Durch die Festlegung von Kapazitäten der Spalten, lässt sich die Menge der Karten pro Spalte begrenzen. Die Priorisierung von Aufgaben innerhalb eines Projektes ... erfolgt grundsätzlich nur zu Beginn. erfolgt in der Regel projektbegleitend. ist in jedem Fall vom Projektleiter vorzunehmen. Die MoSCoW-Methode zum Priorisieren ... gibt die Kategorien „Muss“, „Soll“, „Kann“, „Darf“ und „Nicht umsetzen“ vor. hilft bei der Kategorisierung einer großen Menge von Anforderungen. eignet sich grundsätzlich für die detaillierte Priorisierung von Anforderungen. Das Team Estimation Game ... ist eine Technik zur Kategorisierung von Anforderungen. ist eine Technik mit der eine Menge an Anforderungen oder Aufgaben vollständig durchnummeriert werden können. ist eine Technik zur Priorisierung, bei der mehrere Personen einbezogen werden. Falls in einem Projekt sehr viele Anforderungen oder Aufgaben priorisiert werden müssen ... müssen dennoch die gesamte Menge der Anforderungen oder Aufgaben mit dem Team Estimation Game priorisiert werden, damit es zu jedem Zeitpunkt im Projekt eine vollständig durchnummerierte Liste gibt. können die Techniken MoSCoW und Team Estimation auch kombiniert angewendet werden. ist von der Beteiligung vieler Personen abzusehen, da man sich sehr leicht in Diskussionen verstrickt. Die Drei-Punkt-Schätzung (PERT) ... berücksichtigt neben einem wahrscheinlichen Aufwand auch Extremfälle (Best Case und Worst Case). basiert auf der Dreiecksverteilung und bezieht zwei konkrete Schätzwerte bei der Berechnung mit ein. berücksichtigt bereits tatsächliche Aufwände während der Schätzung. Phasen eines Softwarelebenszyklus. Was ist was Requirements Engineering Implementierung. Nennen Sie ein Hilfsmittel zur Koordination der an Wartungsaufgaben beteiligten Abteilungen. Typische Aktivitäten der Phase Abschaltung Herauslösung aus Anwendungslandschaft Migration von Daten Verträge kündigen Personal weiterqualifizieren Partner informieren Neue Technologien integrieren. Was beeinträchtigt den Erfolg oder Misserfolg eines Softwareprojekts zwischen Rollen?. Worin unterscheiden sich die Rollen? Konstruktive Betreibende. Was gehört wozu? Prozessparadigma Softwareprozessmodell-Rahmenwerk. Hauptmodelle V-Modell XT Projekttypen Entscheidungspunkte & Projektdurchführungsstrategien Vorgehensbausteine Funktionen Integrationstests. Wie unterstützt RUP die evolutionäre Entwicklung?. Rollen bei Scrum. Managementebenenen PRINCE2 Ebene 1 Ebene 2 Ebene 3 Ebene 4. Managementprozesse den Managementebenen zuordnen Ebene 1 (Programmmanagement) Ebene 2 (Projektlenkungsausschuss) Ebene 3 (Projektleiter) Ebene 4 (Teamleiter). Phasen wo? Phasen eines Softwarelebenszyklus Phasen IT-Projekt in PITPM. Phasen IT-Projekt nach PITM. as MoSCoW Team Estimation Game. Werte bei Aufwandsberechnung.

Report abuse