Welcome to Systems Development!
Have you ever wondered how a massive app like Instagram or a complex booking system for an airline is actually built? It’s not just about sitting down and writing code. It’s like building a skyscraper: you need a solid plan, the right materials, and a clear understanding of who will use the building.
In these notes, we are going to explore Topic 4 (IT Systems) and Topic 10 (Designing Web Pages) from your syllabus. We will learn how to break down big problems into small pieces and how to design systems that are truly "fit for purpose."
1. What Makes Up an IT System?
Before we can develop a system, we need to know what we are working with. An IT System isn't just a computer; it is a combination of four key elements:
- Hardware: The physical parts (servers, tablets, cables).
- Software: The programs and operating systems that tell the hardware what to do.
- Processes: The rules or steps followed to achieve a goal (e.g., the steps to reset a password).
- People: The users who interact with the system and the staff who maintain it.
Analogy: Think of a restaurant. The kitchen and tables are the hardware. The recipes are the software. The way the waiters take orders is the process. The chefs and the hungry customers are the people. You need all four for the restaurant to work!
Decomposing the System
Large systems are scary and complex. To manage this, developers use decomposition. This simply means breaking a large system down into smaller, more manageable sub-systems.
Quick Review: Why decompose?
1. It makes the problem easier to understand.
2. Different teams can work on different parts at the same time.
3. It is easier to test and fix small parts than one giant machine.
Key Takeaway:
An IT system is a mix of hardware, software, processes, and people. Breaking it down (decomposition) makes it easier to build.
2. Design Tools: Flowcharts and Dataflow Diagrams (DFDs)
Developers use "blueprints" to show how a system works before they build it. Two of the most important tools are Flowcharts and Dataflow Diagrams.
Flowcharts (The "How")
A flowchart shows the logic and the step-by-step decisions in a process. It focuses on the sequence of actions.
Example: A flowchart for a login screen would show: Input Username -> Is password correct? -> If Yes, go to Home; If No, show Error.
Dataflow Diagrams (The "What")
A Dataflow Diagram (DFD) shows how data moves through a system. It doesn't care about the order of steps; it cares about where information comes from, where it goes, and where it is stored.
Common Mistake to Avoid: Don't confuse these two!
- Use a Flowchart to show decisions (Yes/No paths).
- Use a DFD to show data movement (e.g., a customer's order moving from a form to a database).
Key Takeaway:
Flowcharts show the logic and steps; DFDs show how information travels through the system.
3. Designing Web Products
When developing for the web, we follow a specific design process to make sure the user has a good experience. Don't worry if this seems like a lot of steps—it's just a way to move from an idea to a finished product.
The Design Journey:
- Wireframes: Simple sketches showing the layout. No colors or images—just boxes to show where things go. (Think of this as the skeleton.)
- Mock-ups: A more detailed visual design. This includes colors, fonts, and images. It looks like the final site but doesn't "work" yet. (Think of this as the skin.)
- Web-design Style Guide: A document that lists the specific colors (hex codes), fonts, and button styles to keep the design consistent.
- Prototyping: An interactive version of the design. You can click buttons to see how the pages link together.
Did you know? Using a style guide ensures that even if ten different people work on a website, it will still look like it was made by one person!
Key Takeaway:
Web design moves from layout (wireframe) to visuals (mock-up) to a working model (prototype).
4. Fitness for Purpose and Performance
Once a system is designed or built, we must evaluate it. The most important question is: Is it fit for purpose?
Fitness for purpose means the system does exactly what the user needs it to do and meets all the original requirements.
Measuring Performance
To know if a system is performing well, we look at:
- Speed: How fast does the processor handle tasks?
- Capacity: How much data can the storage hold?
- Bandwidth: How much data can be sent over the network at once?
- Power Efficiency: Does it drain the battery too fast? (Important for mobile devices!)
The Math of Development
Sometimes you need to calculate if a system can handle a task. For example, calculating how long it takes to send a file:
\( \text{Time} = \frac{\text{File Size}}{\text{Transfer Rate}} \)
Memory Tip: Remember that in IT (IEC units), a Kibibyte (KiB) is \( 2^{10} \) (1024 bytes), not 1000!
Key Takeaway:
A system is only successful if it is "fit for purpose"—meaning it works for the user and meets performance needs like speed and capacity.
Final Summary Checklist
Before your exam, make sure you can:
- [ ] List the four parts of an IT System (Hardware, Software, Process, People).
- [ ] Explain why decomposition is useful.
- [ ] Identify the difference between a Flowchart and a DFD.
- [ ] Describe the difference between a Wireframe and a Mock-up.
- [ ] Define fitness for purpose.
You've got this! Systems development is just a step-by-step way of solving problems. Take it one "sub-system" at a time!