Software Development and Management

Each UML diagram type serves a specific purpose: State diagrams excel at tracking individual object behavior across use cases (A), Interaction diagrams (sequence/collaboration) show message flow between multiple objects within a single use case (B), and Activity diagrams model processes involving multiple objects across multiple use cases (C). All three statements accurately describe appropriate uses of these diagram types.

The Rational Unified Process (RUP) defines four sequential phases: Inception, Elaboration, Construction, and Transition. The selected option correctly lists these four phases, despite a minor spelling error in 'Ellaboration'.

TOGAF guidelines specify that architects should first look for reusable building blocks from their Enterprise Continuum to leverage existing organizational assets before creating new custom components or looking externally.

In TOGAF and enterprise architecture practice, application systems should be described as logical groupings of business capabilities or functions they provide. This abstraction level focuses on what the system delivers for the business, not implementation details like schemas or technical diagrams. Computer systems (A) is too generic, while schemas (C) and data-flow diagrams (D) are implementation-specific views.

In TOGAF's ADM, architecture phases are iterative. If application architecture work reveals significant business architecture gaps or changes, the correct practice is to revisit and refine the business architecture phase rather than force alignment through technology adjustments or workarounds. This ensures business-IT alignment. Options B, C, D, and E represent workarounds or governance circumventions that don't address the root architectural misalignment.

According to TOGAF, Architecture Building Blocks (ABBs) define the required capability and what functionality is needed, whereas Solution Building Blocks (SBBs) define how that functionality will be implemented and with what products.

In Scrum methodology, work is organized into small, time-boxed iterations called Sprints (typically 1-4 weeks). Each Sprint delivers a potentially shippable product increment. The term 'Sprint' is specific to Scrum and represents the heartbeat of development.

A Burndown chart is the specific Scrum tool used to track the progress of work within a Sprint. It shows the amount of work remaining over time, helping the team visualize if they will complete the Sprint backlog by the deadline. Flow charts and status reports are not standard Scrum tracking tools.

Scrum defines three specific roles: the Product Owner (who manages the product backlog and priorities), the Scrum Master (who facilitates the Scrum process and removes impediments), and the Team (who does the actual work). There is no 'Project Manager' role in Scrum - those responsibilities are distributed among the three roles.

In SCRUM, the product backlog is the master list of all desired features, requirements, and work items. It is prioritized by the Product Owner and serves as the single source of truth for what needs to be built. The Sprint backlog is a subset selected for a specific sprint, while a Project log and Business requirements document are not SCRUM artifacts.

In SCRUM, the Product Owner has sole authority to decide the priority of requirements in the product backlog. They represent stakeholders and business value, ordering work to maximize ROI. The Scrum Master protects the process, the Team does the work, and End users provide input but do not directly prioritize.

In SCRUM, the development team is responsible for estimation. They use techniques like planning poker to estimate effort collaboratively. The Product Owner decides what needs to be done (priority), but only the team can assess how much work it involves.

All Agile methodologies use iterative development as a core principle. However, not all iterative methods are Agile - for example, the iterative waterfall model or RUP (Rational Unified Process) are iterative but don't embrace Agile values like individuals over processes or responding to change.

In SCRUM, velocity is the metric that measures a team's productivity - specifically, the amount of work (usually in story points or hours) the team completes per sprint. A burn-down chart tracks remaining work over time, sprints are time-boxes, and velocity is used for predictable planning.