Introduction to Software Development
Welcome! In this chapter, we are going to explore how software is actually created. It isn't just about sitting down and typing code. Just like building a house requires a blueprint, a foundation, and regular repairs, professional software follows a specific process called the Program Development Life Cycle (PDLC). Don't worry if this seems like a lot of steps—we will break it down into simple, logical pieces that make sense!
12.1 The Program Development Life Cycle (PDLC)
The Program Development Life Cycle is a step-by-step process used by developers to create high-quality software. Think of it as a "to-do list" for software engineers.
The Five Main Stages
Every software project generally moves through these five stages:
1. Analysis: Figuring out exactly what the user needs. Developers talk to customers and create a "Requirements Specification."
2. Design: Creating the "blueprints." This includes planning the user interface, the data structures, and the algorithms (using flowcharts or pseudocode).
3. Coding: The actual writing of the program in a language like Python, VB, or Java.
4. Testing: Checking the program for bugs and making sure it meets the requirements from the Analysis stage.
5. Maintenance: Keeping the software running smoothly after it has been released to the users.
Development Models
Different projects need different approaches. Here are the three you need to know:
1. The Waterfall Model
This is a "linear" model. You finish one stage completely before moving to the next. Like a real waterfall, you can't easily go back up! Example: A large government project with very strict requirements.
2. The Iterative Model
Developers create a small version of the software, test it, and then "iterate" (repeat) the cycle to add more features. Example: Developing a mobile app where you release "Version 1.0" and then add more features in "Version 2.0."
3. Rapid Application Development (RAD)
This focuses on building prototypes (early, simple versions) quickly to get feedback from users. It involves a lot of back-and-forth communication. Example: A startup trying to test a brand-new idea to see if people like it.
Quick Review: PDLC Models
• Waterfall: Rigid, step-by-step, hard to change.
• Iterative: Building the software in "loops" or versions.
• RAD: Fast prototypes and constant user feedback.
12.2 Program Design
Before coding, we must plan. Two major tools help us "see" how a program will work before we write a single line of code.
Structure Charts
A Structure Chart is used for decomposition—breaking a big, scary problem into smaller, manageable sub-tasks (modules). It shows how these modules interact and what data (parameters) is passed between them.
Analogy: If "Making Dinner" is the big task, the sub-tasks are "Chopping Veggies," "Boiling Water," and "Setting the Table."
State-Transition Diagrams
These show how a system changes from one "state" to another based on an event.
Example: A vending machine. Its "States" could be Waiting for Coin, Selecting Item, and Dispensing. When you insert a coin, the state "transitions" from Waiting to Selecting.
12.3 Program Testing and Maintenance
Even the best programmers make mistakes! Testing is how we find and fix those mistakes (faults).
Types of Errors
1. Syntax Errors: Like a "grammar mistake" in code. The program won't even start. Example: Writing "prnt" instead of "print".
2. Logic Errors: The program runs, but the result is wrong. Example: You want to add two numbers but you accidentally used the minus sign: \( Result = A - B \) instead of \( Result = A + B \).
3. Run-time Errors: The program starts, but crashes while running. Example: Trying to divide a number by zero \( (x / 0) \).
Testing Methods
How do we find these errors? We use different testing strategies:
• Dry Run / Walkthrough: A person mentally follows the code with a pen and paper using a "Trace Table." No computer is used!
• Black-box Testing: Testing only the inputs and outputs. You don't look at the code inside; you just check if the result is correct.
• White-box Testing: Testing the internal logic of the code. You check every possible path (loops, if-statements) to ensure they all work.
• Alpha Testing: Testing done "in-house" by the developers themselves.
• Beta Testing: Releasing the software to a small group of real users to find bugs in the real world.
• Stub Testing: Using "dummy" code as a placeholder for a module that hasn't been written yet.
Choosing Test Data
To have a good test plan, you need three types of data:
1. Normal Data: Data that should work. Example: If a program accepts ages 1–100, "25" is normal data.
2. Abnormal Data: Data that is clearly wrong. Example: Entering "Banana" or "-5" for an age. The program should reject this.
3. Extreme (Boundary) Data: Data at the very edges of what is allowed. Example: For ages 1–100, "1" and "100" are extreme data. This is where many bugs hide!
Key Takeaway: Maintenance
Once the software is finished, it enters Maintenance. There are three types:
1. Corrective: Fixing bugs that weren't found during testing.
2. Adaptive: Changing the software so it works on a new OS (e.g., updating an app for Windows 11).
3. Perfective: Improving the software (e.g., making it faster or adding a "Dark Mode").
Summary Checklist
✓ PDLC Stages: Analysis, Design, Coding, Testing, Maintenance.
✓ Models: Waterfall (linear), Iterative (loops), RAD (prototypes).
✓ Design Tools: Structure Charts (breaking down tasks) and State-Transition Diagrams.
✓ Errors: Syntax (grammar), Logic (math/logic fail), Run-time (crash).
✓ Testing: White-box (internal), Black-box (external), Alpha (devs), Beta (users).
✓ Data: Normal, Abnormal, and Extreme.
Top Tip: In exams, if you are asked how to fix a logic error, remember that a Dry Run using a Trace Table is the best way to find exactly where the math went wrong!