Topic 1 - Types of software
1.1 Programs vs applications
A program is a set of instructions that performs a specific, individual task. It may have no user interface (e.g. a background OS process) and is written in a language like Python or Java.
An application is made up of one or more programs, designed to be user-friendly and help users complete tasks. Examples: Microsoft Word, Chrome, Instagram.
May have no user interface.
Can be reused as a sub-program in multiple applications.
Translated into a format the computer understands and then run.
Has a user interface (menus, buttons, etc.).
May be designed for a specific OS (e.g. iOS app).
May involve multiple programs working together.
Devices: desktops/laptops, consoles, smart TVs, smart speakers, smartphones, AR/VR devices, and embedded systems (washing machines, cars).
1.2 Operating systems
Justify OS choice based on the client scenario, e.g. building an iOS app = must use proprietary; museum terminal = open OS (customisable and low cost).
1.3.1 Application types (8 types)
1.3.2 Software categories (5)
1.3.3 Software types (3)
Justify choice against the client scenario, e.g. dental surgery bookings = bespoke (unique needs); general office = off-the-shelf (cost-effective).
Topic 2 - Software development models
2.1 Seven development models
Throwaway vs evolutionary: both use prototypes, but throwaway discards them after gathering feedback; evolutionary refines the prototype until it becomes the final product.
2.2 Phases of software development
Seven phases that interact and iterate (e.g. testing may reveal design issues, requiring you to return to the design phase).
Phased: rolled out in stages.
Parallel: old and new systems run simultaneously until the new one is trusted.
Big bang (crash): old system replaced all at once.
Topic 3 - Planning development projects
3.1 Importance of planning
Identifies required resources (time, money, people, tools).
Better organisation, as team members know their roles.
Improves time management via deadlines and milestones.
Plans may become outdated if requirements unexpectedly change mid-project.
Unclear goals leading to confusion and delays.
Risk of delivering an unusable or incomplete product.
Planning considerations (things that must be evaluated in the planning phase):
Budget, timescales, team/human resources, available hardware and software, scalability requirements, security needs, and legislation compliance.
Three types of legislation to be aware of (you don't need specific law names):
- Copyright: protecting original work from unauthorised use.
- Data protection: how personal data must be handled and stored. Breaches can result in fines up to £17.5m or 4% of global turnover.
- Electronic communication: rules around sending digital messages, cookies and electronic marketing.
3.2 Project planning tools (6)
Opportunities & Threats = external (outside control).
Guides decision-making by highlighting advantages, weaknesses to address and potential risks.
Topic 4 - Application design scoping
4.1 Gathering client requirements (9 methods)
4.2 Client requirement specifications
A client requirement specification formally documents exactly what the system must do and how it must operate. Know all elements:
4.3 Decomposition methods (4)
Decomposition breaks complex problems into smaller, manageable parts, making development easier to plan, understand and implement. Reduces errors and improves efficiency.
Top-down = start broad, go specific. Bottom-up = start specific, build up. Abstraction = filter out irrelevant detail. Parsing = break requirements into actionable tasks.
Topic 5 - Human-Computer Interface (HCI)
5.1.1 Types of human-computer interaction
GUI vs CLI: GUI is accessible, visual, and suited to general users. CLI is powerful, efficient for experts, but has a steep learning curve and no visual interface.
5.1.2 Types of device
Know the characteristics of each device type that uses application software and how those characteristics influence which HCI types are appropriate.
5.2 Visual design considerations
5.3 HCI design documents and diagrams (4)
Level 0: context diagram, high-level overview.
Level 1: more detailed breakdown of individual processes.
Wireframe = structure only, no styling. Visualisation diagram = shows what it will look like. DFD = data flow, not logic or decisions. Flowchart = step-by-step sequence and decision paths.
Topic 6 - Job roles & communication skills
6.1 Job roles in application development (7)
UXD = how it feels to use (research, testing, behaviour). UID = how it looks (visual design). Systems analyst = requirements gathering. Systems designer = technical architecture.
6.2 Communication skills (5)
Closed questions: yes/no, confirm specific facts.
Probing questions: explore detail further.
Clarifying questions: check understanding is correct.
Topic 1 - Application software considerations
1.1 Application platforms
The spec defines three application platforms. Know the uses, advantages and disadvantages of each.
Advantages: immersive, hands-on learning without real-world risk. Disadvantages: expensive hardware, can cause discomfort, development complexity.
Advantages: accessible on any browser, no installation, easy to update. Disadvantages: requires internet, may be slower than native apps, security risks (spoofing).
Note: the spec's platform categories are AR/VR/MR, Websites, and Computer games. "Mobile app" or "desktop app" are NOT platform categories. Those are devices (1.2), not platforms.
1.2 Devices
Know the characteristics, advantages and disadvantages of each device that application platforms run on.
1.3 Storage locations
On-site storage: physical storage at the organisation's own location.
Cloud storage: data stored on remote servers accessed via the internet. Two things to know: locations and types.
Cloud storage locations:
Cloud storage types:
The spec distinguishes cloud storage locations (private/public/hybrid/community) from cloud storage types (file/object/block/elastic/database). Know both sets separately.
Topic 2 - Data and flow in application software
2.1 Data formats and data types
Data formats: how data is structured and encoded for storage or transmission:
Data types: the kind of value a variable stores in a program:
2.2 Data flow
Data vs information: data is raw, unprocessed facts (e.g. "42", "Liverpool"). Information is data that has been processed and given context and meaning (e.g. "42 students are enrolled at Liverpool campus"). Data is converted to information by processing it: sorting, calculating, combining with other data.
Types of input data that flow into an application:
Black box concept: a model where the system's internal processing is hidden. Only inputs and outputs are visible to the user. Data flows in, is processed internally, then flows out as information, or flows to storage. Used to diagrammatically represent data flow without showing the internal logic.
The three flows: flow in (input data enters the system), flow to storage (data saved to on-site or cloud), flow out (information produced as output: number, text, audio, image, movement).
2.3 Data states
Topic 3 - APIs and protocols
3.1 Application Programming Interfaces (APIs)
An API sets the rules enabling one application to communicate with another, defining how requests and responses are structured. Role: enables communication between a server and application; transfers data between systems; increases security by controlling access.
API types:
API architectures:
REST = flexible, lightweight, widely used. SOAP = strict, XML-based, enterprise-grade security. RPC = calling a remote function directly.
3.2 Protocols and the TCP/IP stack
A protocol is a set of rules governing how data is transmitted and received. The spec lists nine protocols to know:
TCP/IP stack - 4 layers (top to bottom):
The spec says "does not include OSI model": only the 4-layer TCP/IP stack is needed, not the 7-layer OSI model.
Topic 4 - Application software security
4.1 Security threats and mitigations
Threats to application security (spec says no need for detailed workings; know the risk each poses):
Physical security mitigations:
Digital security mitigations:
The spec says "does not include details of specific threats or the specific workings of mitigations": focus on the risk each threat poses and how each mitigation protects against it.
Topic 5 - Operational considerations
5.1 Testing
Test plan structure: know all fields:
Types of test data:
Types of testing:
5.2 Types of application software installation
The spec says "does not include completing software installations": you need to know the process, advantages/disadvantages and when to use each type, not how to physically do it.
5.3 Policies
Know the purpose and content of each policy that must be considered when developing and deploying application platforms.
Topic 6 - Legal considerations
6.1 Legislation and the ICO
For F161 you must know specific Acts by name, their main purpose, what compliance requires, the impact of non-compliance, and how they relate to each other. The spec says "does not include knowing the detailed content": know the purpose and obligations, not every clause.
Non-compliance: fines up to £17.5m or 4% of global turnover, reputational damage, enforcement notices.
Enforced by the ICO.
Non-compliance: criminal prosecution, imprisonment, fines.
Relationship to DPA/UK GDPR: PECR works alongside UK GDPR. UK GDPR sets the standard for how consent must be obtained; PECR specifies when consent is required for electronic communications.
Non-compliance: ICO fines up to £500,000.
Non-compliance: ICO enforcement, mandatory disclosure orders, reputational damage.
Key relationship to know: PECR requires consent for electronic marketing; UK GDPR defines what valid consent looks like. They work together. Both are enforced by the ICO.