Aspects of Software Development (Syllabus 3.3.4)
Hello future software engineers! This chapter moves us away from writing individual lines of code and makes us think like project managers. Developing software isn't just about coding; it’s a disciplined process of planning, building, and checking. Understanding this process, often called the Software Development Life Cycle (SDLC), is crucial for creating reliable, efficient, and useful computer systems.
Don't worry if this seems like a lot of steps—we use a similar process every time we tackle a complex task in real life, like organizing a school event or renovating a room!
The Phases of Software Development
Software development is typically broken down into several key stages. While sometimes presented as a rigid sequence (like a Waterfall model), modern development often uses an iterative or agile approach, meaning you cycle through these phases multiple times, refining the product each time.
Phase 1: Analysis
This is the "figure out what the user actually wants" stage. If you build the wrong thing perfectly, you still fail!
Before any construction begins, the problem must be clearly defined.
Key Steps in Analysis:
1. Establish Requirements:
- This involves detailed interaction with the intended users (the people who will actually use the system).
- We need to clarify exactly what the system must do (functional requirements) and how well it must do it (non-functional requirements, like speed or security).
2. Create a Data Model:
- This involves figuring out what data the system needs to store and how that data relates to each other.
- Example: If you are building a school register system, you need to model entities like Students, Classes, and Teachers, and define the attributes for each.
Did you know? The process of clarifying requirements often involves prototyping or an agile approach. This means creating a quick, basic working version (a prototype) to show the user early, so they can say, "Wait, that button needs to be blue, not red!" before you spend months coding the final version.
The core job here is defining the problem, gathering requirements from users, and planning the required data model.
Phase 2: Design
Once we know *what* to build (Analysis), the Design phase determines *how* we will build it. This phase specifies the solution before writing a single line of final code.
Key Design Components:
- Planning Data Structures: Deciding how the data model will be implemented in code (e.g., using arrays, lists, or records).
- Designing Algorithms: Creating the step-by-step procedures (the algorithms, often written in pseudocode) that solve the specific parts of the problem.
- Modular Structure: Breaking the program down into smaller, manageable, named blocks of code (subroutines or functions). This is essential for Structured Programming (covered in 3.3.1) and makes the code easier to test and maintain.
- Designing the Human User Interface (HUI): Planning how the screen looks and how the user interacts with the system (e.g., button placement, navigation flow).
Like Analysis, the Design phase can also be iterative, especially when using a prototyping or agile methodology.
The core job here is planning the structure (modules), the data organisation, and the step-by-step logic (algorithms).
Phase 3: Implementation
This is where the actual coding happens! You take the plans (algorithms and designs) and turn them into executable code.
The models and algorithms designed in the previous phases are translated into data structures and code (instructions) that the computer can process.
When using an iterative/agile approach, developers often focus on the critical path first.
What is the Critical Path?
The critical path is the part of a solution that everything else depends upon. If the critical path isn't functioning, the whole system fails or cannot proceed.
Analogy: If you are building an online store, the ability to process a payment is the critical path. Without payment processing, the entire store is useless, regardless of how good the product display looks.
Writing the code, converting algorithms into instructions, and tackling the critical path first in iterative development.
Phase 4: Testing
Implementation is never finished until the program is rigorously tested! The goal is to find errors (bugs) and ensure the system behaves exactly as the requirements specify.
Students must have practical experience designing and applying various types of test data:
1. Normal (Typical) Data
Purpose: To check that the implementation works correctly under expected, valid conditions.
Example: A program asks for an age between 18 and 60. Normal data would be 35 or 42.
2. Boundary Data
Purpose: To check the extremes of acceptable input. Programs often fail precisely at the boundary limits.
Example: For the age range 18 to 60, boundary data includes 18, 17 (just outside), 60, and 61 (just outside).
3. Erroneous Data (Invalid Data)
Purpose: To check how robust the program is when given completely wrong or unexpected data types.
Example: Entering "Tuesday" or "-5" when an age is expected. The program should handle this gracefully (e.g., display an error message) and not crash.
Testing confirms correctness using planned test data sets: Normal (expected), Boundary (limits), and Erroneous (invalid).
Phase 5: Evaluation
After the system is built and tested, we must look back and judge its quality. This involves comparing the final system against the initial requirements and using key criteria.
You need to know the criteria for evaluating a computer system:
1. Correctness
- Does the program meet all the original user requirements specified in the Analysis phase?
- Does it produce the right output for the right input? (i.e., is it free of bugs?)
2. Efficiency
- Does the system use computing resources well?
- We measure this in terms of time-efficiency (how fast the algorithm runs, often related to the choice of algorithm) and space-efficiency (how much memory the program uses, related to the choice of data structures).
3. Maintainability
- Is the system easy to understand, debug, and update in the future?
- High maintainability means the code is well-structured (modular), uses meaningful identifier names, and includes explanatory comments.
- Encouragement: Writing good comments and clear variable names is essential for maintainability—it saves time and headaches later!
Summary of the Software Development Cycle
A robust system moves through these stages, often cycling back to an earlier stage (especially Analysis or Design) when a prototype fails testing or user feedback changes the requirements.