1
← Back to quizzesFree quiz
Fundamentals of Software Engineering
One of the fundamental differences between software and hardware lies in how they are produced. While hardware requires raw materials, manufacturing processes, and assembly lines, software…
0 / 10
Score: 0%
2
A legacy banking system written in COBOL runs on a mainframe. Which of the following is NOT a typical problem of such legacy software?
3
In the Spiral Model, which quadrant focuses on building prototypes to reduce identified risks?
4
A project team delivers software on time but has no shared documentation or processes. According to CMMI, which maturity level best describes this situation?
5
When comparing the Waterfall and Incremental models, which statement correctly identifies a key limitation of the pure Waterfall approach?
6
A software product line aims to share core assets across multiple market variants. Which benefit is most directly achieved by this approach?
7
During the testing phase of an XP project, which activity ensures that the code meets the customer’s expectations before release?
8
Which agile principle directly supports the practice of delivering working software frequently, as stated in the 12‑point list?
9
In the V‑Model, which testing activity is paired with the Low‑Level Design phase?
10
A software project adopts the Component‑Based Development (CBD) model. Which risk is most likely to arise during integration?
Understanding Why Software Duplication Is Inexpensive
One of the fundamental differences between software and hardware lies in how they are produced. While hardware requires raw materials, manufacturing processes, and assembly lines, software is developed once and then copied as many times as needed. This characteristic makes reproducing software copies virtually cost‑free.
- Copying a program is as simple as duplicating a file on a disk or downloading it from a server.
- Hardware replication involves material costs, tooling, and labor for each unit.
- The key mnemonic Develop‑Not‑Manufacture (DNM) helps you remember that software is created, not manufactured.
Think of a recipe (software) that you can print countless times versus a car (hardware) that must be built from scratch for each buyer. This analogy reinforces why software distribution scales dramatically.
Legacy Systems: Common Challenges and Misconceptions
Legacy applications, such as a COBOL banking system running on a mainframe, often raise concerns about maintainability and cost. Typical problems include:
- Complex, tightly coupled code that makes changes risky.
- Scarcity of skilled developers familiar with outdated languages.
- High operational and maintenance expenses due to aging hardware and specialized support.
It is a misconception that legacy hardware frequently fails because of wear; mainframes are designed for long‑term reliability. The real issue is the software’s rigidity, not the hardware’s durability.
The Spiral Model: Risk‑Driven Development
Quadrants Overview
The Spiral Model visualizes software development as a series of spirals, each divided into four quadrants:
- Top‑Left: Objectives, alternatives, and constraints.
- Top‑Right: Evaluate alternatives, identify and resolve risks (including prototyping).
- Bottom‑Left: Review and plan the next phase.
- Bottom‑Right: Develop and verify the next‑level product.
The Top‑Right quadrant is where teams build prototypes to test risk. This practice allows early detection of technical or usability issues before committing to full‑scale development.
Mnemonic: Top‑Right = Test Risk (TR). Visualize the spiral as a clock; the “right” side is where you “right‑hand” the risk by creating a prototype.
CMMI Maturity Levels: Recognizing Process Capability
The Capability Maturity Model Integration (CMMI) defines five maturity levels that describe an organization’s process sophistication. When a team delivers software on time but lacks shared documentation or repeatable processes, it aligns with Level 1 – Initial:
- Ad‑hoc, individual‑driven work.
- No formalized procedures or metrics.
- Success depends on heroic effort rather than systematic practice.
Mnemonic: “I” for “Individual” – Level 1 relies on individuals, not on defined processes. Imagine a starter recipe with no written steps; you can still bake a cake, but only because the chef knows the tricks.
Waterfall vs. Incremental: Limitations of the Pure Waterfall Approach
The classic Waterfall model assumes a linear progression where each phase is completed before the next begins. A key limitation of this pure approach is the unrealistic expectation that no errors will be introduced in any phase. In practice, requirements change, design flaws emerge, and testing often uncovers defects that ripple backward through the lifecycle.
Because Waterfall does not accommodate iterative feedback or overlapping activities, it can lead to costly rework when errors are discovered late. Incremental models address this weakness by delivering small, functional slices of the system early and refining them based on stakeholder feedback.
Software Product Lines: Leveraging Core Asset Reuse
A software product line (SPL) is a strategic approach that shares a common set of core assets—such as libraries, frameworks, and architectural components—across multiple market variants. The most direct benefit of an SPL is reduced development time through reuse of tested components. By reusing proven assets, teams can focus on customizing features rather than reinventing the wheel.
While SPLs improve efficiency, they do not guarantee zero defects, eliminate all customization effort, or remove reliance on third‑party libraries. Instead, they provide a foundation that accelerates delivery and enhances quality consistency.
Extreme Programming (XP) Testing Practices
In XP, testing is integral to ensuring that the software meets the customer’s expectations. The activity that directly validates the product against user requirements is conducting acceptance tests defined by the customer. These tests are written in collaboration with the client and executed before each release, confirming that the delivered functionality aligns with business goals.
Other XP practices—pair programming, daily unit test runs, and code walkthroughs—support overall quality but do not replace the explicit verification provided by acceptance testing.
Agile Principles: Delivering Working Software Frequently
Among the twelve Agile principles, the one that explicitly promotes frequent delivery is:
“Deliver working software frequently, from a couple of weeks to a couple of months.”
This principle encourages short iteration cycles, enabling stakeholders to see tangible progress, provide feedback, and adjust priorities quickly. It contrasts with principles focused on simplicity, embracing change, or face‑to‑face communication, which support the overall agile mindset but do not directly address delivery cadence.
Key Takeaways Across All Topics
- Software duplication is cheap because software is developed, not manufactured.
- Legacy systems suffer from code complexity, skill shortages, and high maintenance costs—not hardware wear.
- In the Spiral Model, the Top‑Right quadrant is dedicated to prototyping for risk reduction.
- CMMI Level 1 describes ad‑hoc, undocumented processes despite on‑time delivery.
- Pure Waterfall assumes error‑free phases, a limitation overcome by incremental approaches.
- Software product lines accelerate development by reusing core assets.
- XP acceptance tests verify that the product meets customer expectations before release.
- Agile’s frequent delivery principle drives short, value‑focused iterations.
By mastering these concepts, you’ll be better equipped to analyze software engineering models, assess process maturity, and apply agile practices effectively.
