51. What is a Sprint in Scrum methodology?
- A sudden burst of intense coding activity by the development team at project end
- A fixed-length iteration in Scrum (typically 1-4 weeks) during which the development team works to complete a set of Product Backlog items and deliver a potentially shippable product increment
- A testing phase where the QA team sprints through all test cases in one day
- A project phase where the project manager reviews all deliverables simultaneously
Answer : B Explanation: A Sprint (also called an iteration) is the heart of Scrum. Key characteristics: Fixed duration (time-boxed) — typically 2 weeks, consistent throughout the project. Begins with Sprint Planning where the team selects backlog items and creates the Sprint Goal. Daily Scrums (standups) keep the team synchronized. Ends with a Sprint Review (demonstrating working software to stakeholders) and Sprint Retrospective (team reflects on process improvements). The output is a “Done” increment of potentially releasable software. Sprints provide a predictable cadence, enable frequent feedback, and allow the team to adapt to changing requirements every few weeks.
52. What is the role of a Scrum Master?
- The senior developer who writes the most code and technically leads the Scrum team
- A servant-leader who facilitates Scrum events, coaches the team on Agile principles, removes impediments, and protects the team from external distractions — without having authority over the team
- The project manager who assigns tasks to development team members each day
- The customer representative who decides which features are built in each sprint
Answer : B Explanation: The Scrum Master is a servant-leader — they serve the team, not manage it. Key responsibilities: Facilitating Scrum events (Sprint Planning, Daily Scrum, Sprint Review, Retrospective), Coaching the team on Agile/Scrum principles and practices, Removing impediments (blockers that slow the team down), Shielding the team from external interruptions, Helping the Product Owner manage the backlog, and Facilitating organizational change to increase Scrum adoption. The Scrum Master does NOT assign tasks, make business decisions, or manage the product backlog. They are accountable for the Scrum process being effective, not for the product delivered.
53. What is a Product Backlog in Scrum?
- A list of all software bugs found during the testing phase of a sprint
- An ordered list of everything that might be needed in the product — features, bug fixes, technical work, and knowledge acquisition — maintained and prioritized by the Product Owner
- A document listing all team members’ daily tasks and assignments
- A record of all previously completed sprints and their delivered features
Answer : B Explanation: The Product Backlog is the single source of requirements for any changes to be made to the product. Key characteristics: it is ordered (highest-priority items at the top), dynamic (constantly evolving as new requirements emerge), and maintained by the Product Owner. Items in the backlog are called Product Backlog Items (PBIs) or User Stories. The top items are refined (broken down and estimated) and ready for sprint planning; lower-priority items may be vague. Backlog Refinement (Grooming) is an ongoing activity where the team reviews, estimates, and adds detail to backlog items. The Product Backlog is never “complete” — it exists as long as the product exists.
54. What is a User Story in Agile project management?
- A detailed technical specification document written by a software architect
- A short, simple description of a feature from the end user’s perspective, typically written in the format: “As a [user type], I want [goal] so that [reason/benefit]”
- A narrative report documenting the history of a software project from start to finish
- A testing scenario that describes how a user would interact with a completed system
Answer : B Explanation: User Stories are the primary way Agile teams capture requirements from the user’s perspective. Standard format: “As a [type of user], I want [some goal] so that [some reason].” Example: “As a registered customer, I want to save my payment details so that I can check out faster on future visits.” User stories follow the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Each user story has Acceptance Criteria — conditions that must be met for the story to be considered complete. User stories keep focus on user value rather than technical specifications, encouraging conversation between developers and stakeholders.
55. What is software configuration management (SCM)?
- A process for configuring hardware servers used to run software applications
- The discipline of tracking and controlling changes to software artifacts including source code, documentation, and configuration files — ensuring integrity and traceability throughout the software lifecycle
- A management technique for configuring the software development team’s roles
- The process of setting up software development tools and IDE configurations
Answer : B Explanation: Software Configuration Management (SCM) manages changes to software systematically to maintain integrity and traceability. Key activities: Configuration Identification (identifying and labeling all software artifacts), Version Control (tracking changes over time using tools like Git), Change Control (formal process for evaluating and approving changes), Configuration Auditing (verifying that software matches its specification), and Configuration Status Accounting (recording and reporting SCM activities). Git is the most widely used version control system, with platforms like GitHub, GitLab, and Bitbucket hosting repositories. SCM prevents common problems like “it worked on my machine” and ensures teams can track exactly what changed and when.
56. What is the purpose of software testing in project management?
- To find all bugs in the software and then fix them before adding any new features
- To verify that the software meets specified requirements and to identify defects before delivery, ensuring the product functions correctly and meets quality standards
- To document how the software works for future maintenance reference only
- To measure the performance of individual developers on the project team
Answer : B Explanation: Software testing verifies and validates that the software meets requirements and works as expected. Testing levels: Unit Testing (testing individual components in isolation), Integration Testing (testing how components work together), System Testing (testing the complete integrated system), User Acceptance Testing — UAT (customers verify the system meets their requirements). Testing types: Functional (does it do what it should?), Non-functional (performance, security, usability), Regression (does new code break old functionality?), and Smoke Testing (basic sanity check). Agile teams use Test-Driven Development (TDD) — writing tests before code. The cost of fixing defects increases dramatically the later they are found.
57. What is the difference between verification and validation in software engineering?
- Verification tests the final product; validation checks the design documents only
- Verification checks “Are we building the product right?” (conformance to specifications); Validation checks “Are we building the right product?” (meeting actual user needs)
- Validation is performed by developers; verification is performed by end users only
- Both verification and validation are identical activities performed by the QA team
Answer : B Explanation: Verification and Validation (V&V) are two complementary quality assurance processes. Verification — “Are we building the product right?” — checks that the software correctly implements specific requirements at each stage. Activities include: reviews, inspections, walkthroughs, and static analysis. It does NOT require running the software. Validation — “Are we building the right product?” — checks that the final product meets the customer’s actual needs and intended use. Activities include: User Acceptance Testing (UAT), beta testing, and field testing. Barry Boehm’s memorable phrase: “Verification: Are we building the product right? Validation: Are we building the right product?”
58. What is function point analysis in software project management?
- A performance analysis technique that counts the number of functions a developer writes per day
- A software size measurement technique that quantifies functionality from the user’s perspective by counting inputs, outputs, user interactions, files, and interfaces — used for effort and cost estimation
- A testing technique that analyzes each function in the software for defects
- A project planning tool that assigns point values to tasks for sprint velocity tracking
Answer : B Explanation: Function Point Analysis (FPA), developed by Allan Albrecht at IBM in 1979, measures software size based on functionality rather than lines of code (LOC). It counts five types of function points: External Inputs (EI), External Outputs (EO), External Inquiries (EQ), Internal Logical Files (ILF), and External Interface Files (EIF). Each is rated as low, average, or high complexity. Unadjusted function points are calculated, then a Technical Complexity Factor (TCF) is applied. Function points are technology-independent — the same function point count applies regardless of programming language, enabling cross-project comparisons and historical estimation data.
59. What is the COCOMO model in software project management?
- A project communication model that defines how team members should collaborate
- A software cost estimation model (COnstructive COst MOdel) that estimates development effort, schedule, and cost based on the size of the software in lines of code and various cost drivers
- A quality assurance model that defines the steps for software code review
- A customer communication model for managing stakeholder expectations during development
Answer : B Explanation: COCOMO (COnstructive COst MOdel), developed by Barry Boehm in 1981, is one of the most widely used software cost estimation models. Basic COCOMO formula: Effort (person-months) = a × (KLOC)^b, where KLOC is thousands of lines of code and a, b are constants depending on project type. Three project types: Organic (small, simple — a=2.4, b=1.05), Semi-detached (medium complexity — a=3.0, b=1.12), and Embedded (complex, real-time — a=3.6, b=1.20). COCOMO II is the updated version that works with function points and object points, making it more applicable to modern development approaches.
60. What is software quality assurance (SQA) in project management?
- A process that automatically fixes software bugs without human intervention
- A set of planned and systematic activities that provide confidence that a software product and processes conform to established technical requirements and management needs
- A team responsible only for testing the final version of software before release
- A financial audit process that ensures software project budgets are spent correctly
Answer : B Explanation: Software Quality Assurance (SQA) is process-oriented — it ensures that development processes are followed correctly so quality is built into the product, not just tested at the end. SQA activities include: process definition and documentation, process audits and reviews, standards compliance verification, training, metrics collection and analysis, and corrective action management. SQA differs from software testing (which is product-oriented — finding defects in the finished product). Together, they form a comprehensive quality management approach. Key standards include ISO 9001, CMMI (Capability Maturity Model Integration), and IEEE software quality standards.
