3.1.1 - Formative project skills: choosing a computational problem
A promising computing problem has more than a topic: it has information that can be represented and decisions that a program can carry out. You will practise explaining computational suitability, choosing a manageable scope and recognising the evidence and tooling needed for a project. Every example and activity here is formative project-skills practice; it does not complete or certify H446/03 assessed work.
From a situation to a computational problem
A problem becomes computationally tractable when relevant information can be represented, rules can be stated precisely and a useful result can be produced from the information.
Inputs are the data supplied to a system; processing transforms or makes decisions about that data; outputs communicate the result. Identifying these is a start, but suitability needs justification: explain how each feature enables a computational method in this particular situation.
Consider a fictional shared rehearsal space. A booking records a room identifier, a date, a start time and an end time. Two bookings clash when they use the same room on the same date and their time intervals overlap. The rules allow one booking to finish exactly when another begins. Representing times consistently lets a program compare them; storing bookings as records lets it repeat that comparison for every relevant booking. A clash warning is an identifiable output. “There will be a database” alone does not explain why the problem can be solved.
The problem also contains a human boundary. A program can detect clashes using the stated rule, but it cannot decide whether an unpopular band deserves priority unless the organisation supplies a legitimate priority policy. A model deliberately represents the relevant part of reality. Leaving musical taste outside this model makes its decisions more defensible, rather than less sophisticated.
Before choosing an approach, ask whether required data can actually be obtained, whether exceptional cases can be expressed and whether a result can be checked. If a room has no recorded capacity, a capacity check cannot work merely because it would be useful.
Why computation helps this problem
Being representable is different from having a good reason to computerise a task.
An amenable problem is one for which a computational approach fits the work and constraints. Connect a property of the work to a mechanism and then to a benefit. In the rehearsal example, every new booking must be compared with existing bookings. Automating the same interval rule reduces repeated manual checking and can warn during entry, before an organiser promises a room. The stored records also allow the check to be repeated after a booking changes. “Computers are fast and accurate” leaves out the work being accelerated and the conditions on accuracy.
A computer applies the implemented rule consistently. It does not guarantee that the rule, input or implementation is correct. A wrong room identifier may hide a clash. Inaccurate records can produce confidently wrong outputs, so validation and checking remain necessary.
Compare a computational approach with the actual alternative. A paper timetable may be sufficient for one rarely used room and a few bookings. If changes are frequent and several organisers need the current schedule, the costs of keeping paper copies consistent become more significant. The justification depends on volume, frequency, reliability needs and available resources; it is not a claim that every manual activity needs software.
Some problems should be partly automated. A rehearsal organiser might use the program to identify conflicts while retaining responsibility for negotiating an exception. Explain what the program can establish and what a person must judge. Adding an undefined “AI decision” does not remove that distinction.
Manageable scope with meaningful coded work
Scope describes what a solution will cover; depth concerns the reasoning and coded work needed to deliver it.
A large feature list can still have little computational depth. A catalogue with many pages but only static text does not become a substantial coded solution by adding more pages. Conversely, a tightly scoped problem can require meaningful validation, data structures, interacting rules and algorithms. These are possibilities to justify from the problem, not a checklist that every project must contain.
For a fictional puzzle-training tool, the first idea is “show a random puzzle”. A more substantial area for investigation could be choosing practice based on a history of attempted skill categories, with transparent selection rules and suitable stored records. The depth would come from the learner's own implemented reasoning and integration, not from the number of puzzle images. This miniature comparison teaches appraisal; it is not a project title to adopt for assessment.
Feasibility depends on time, skills, access to data, hardware and testing opportunities. A plan involving unfamiliar networking, mobile devices and a third-party payment service has several uncertainties. Removing payment processing may preserve the important problem while reducing dependence on an external service. Place optional enhancements outside the agreed core and explain their omission. Do not silently remove a feature that solves the user's main difficulty.
Libraries and built-in operations can be appropriate. Using a library does not require recreating its internals, but a project still needs a substantial element written by the candidate. Installing a game engine or invoking a model is not evidence of that element. A polished interface alone does not prove depth. A short console demonstration can be useful preparation while remaining far smaller than an assessed project.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account