Computer Science 9618/23 — October/November 2022

Background Concept

A development life cycle is a structured way of building software by dividing the work into stages such as analysis, design, coding, testing, implementation and maintenance. Instead of treating development as one large task, the project is managed step by step.

The main purpose of a life cycle is to make software development more organised and controllable. It helps developers, managers and users know what should happen next and what outputs should be produced at each stage.

Understanding the Question

This part asks for just one benefit of using a development life cycle when creating the shopping website. Because it is only one mark, a short, clear benefit is enough.

The question is about why using stages is useful, not about naming the stages themselves.

Approach

Think of what a life cycle improves during a project. Typical acceptable ideas include:

• easier planning
• easier monitoring of progress
• better documentation
• easier testing and review
• clearer structure for the team

For a one-mark answer, choose one benefit and state it directly.

Step-by-Step Reasoning

A strong answer is that the life cycle splits the work into stages. Once work is split into stages:

• deadlines can be set for each stage
• progress can be checked against those stages
• problems can be noticed earlier if a stage is delayed

So the benefit is that the project becomes easier to plan and monitor.

Key Takeaways

• A development life cycle provides structure.
• Its benefits are usually about planning, control, documentation and quality.
• For a one-mark "state" question, one clear point is enough.

Common Mistakes

• Describing a stage instead of giving a benefit. For example, saying "analysis happens first" does not answer the question.
• Giving a vague answer such as "it is better" without saying why.
• Writing several weak ideas instead of one precise benefit.

Things to Be Careful About

• The command word is "State", so keep the answer short and direct.
• Make sure the point is actually a benefit of using the life cycle, not just a feature of websites.
• Avoid overexplaining in a one-mark question; clarity is more valuable than length.

Background Concept

The analysis stage of the program development life cycle is where the problem is investigated and the user's needs are identified. The aim is to understand what the system must do before deciding how to build it.

A key output of analysis is documentation that records these requirements clearly. This becomes a reference for later stages such as design and testing.

Understanding the Question

The question asks for one document that may be produced from the analysis stage of the website project. It is not asking for a stage, a task, or a benefit. It specifically wants a document.

A standard answer is a requirements specification, which lists what the user needs the system to do.

Approach

Think of what is written down during analysis. The most common answer is the requirements specification because analysis is focused on identifying and recording requirements.

Step-by-Step Reasoning

During analysis, developers gather information from the user or client about:

• what the website must do
• what inputs and outputs are needed
• any restrictions or performance needs

These details are usually written into a requirements specification document. That document is then used in later stages to guide the design and to check whether the finished system meets the original needs.

Key Takeaways

• Analysis is about understanding the problem and user requirements.
• A common output from analysis is the requirements specification.
• In life-cycle questions, remember both the purpose of each stage and the documents it produces.

Common Mistakes

• Naming a later-stage document, such as test plan or program code, instead of an analysis document.
• Giving a process instead of a document, for example "interviewing users".
• Writing just "specification" without being clear enough when a more precise term is expected.

Things to Be Careful About

• The question says "may be produced", so one valid document is enough.
• Keep the answer as the document name, not a long description of the whole analysis stage.
• Do not confuse analysis with design: design documents describe how the system will be built, while analysis documents describe what is needed.

Background Concept

Rapid Application Development (RAD) is a software development life cycle that focuses on producing working versions of a system quickly and improving them through repeated refinement. It is different from a strict linear model because development does not simply move once through a fixed sequence.

Common RAD principles include:

• iterative development
• prototyping
• frequent user involvement
• fast delivery of working versions

Understanding the Question

This part asks for one principle of RAD. Because it is one mark, you only need one clear identifying feature.

The phrase "principle of this life cycle" means a core idea that RAD is based on.

Approach

Choose one strong feature that clearly distinguishes RAD, such as:

• building prototypes
• involving users frequently
• developing in iterations

A concise statement combining these is also acceptable.

Step-by-Step Reasoning

RAD works by creating an early working version of the system, showing it to users, collecting feedback, and then improving it in the next cycle. That means it is iterative and often based on prototypes with frequent user feedback.

Any one of those ideas would identify RAD correctly. A strong answer combines them neatly.

Key Takeaways

• RAD is based on speed, iteration and user feedback.
• Prototypes are central to RAD.
• One clear defining feature is enough for a one-mark answer.

Common Mistakes

• Saying only "it is fast". That is true, but it is weaker than naming the actual principle that makes it fast.
• Describing waterfall instead, such as saying each stage is completed only once before the next begins.
• Giving a benefit instead of a principle.

Things to Be Careful About

• Keep the answer focused on what RAD is based on, not whether it is good or bad.
• Make sure the feature really belongs to RAD and is not just a general fact about software development.
• For one mark, one precise principle is better than several vague phrases.

Background Concept

RAD and waterfall are two different software development models.

• Waterfall is linear: one stage is completed before the next begins.
• RAD is iterative: prototypes are built quickly, reviewed, and improved repeatedly.

Because of this difference, RAD tends to emphasise speed and user feedback, while waterfall emphasises formal structure and clear stage completion.

Understanding the Question

This question asks for two benefits and one drawback of using RAD compared to waterfall. That comparison matters: you should think about what RAD does better than waterfall, and what trade-off comes with it.

Since the command says give two benefits and one drawback, your answer should contain exactly those three clear points.

Approach

Compare the models in terms of:

• development speed
• ability to respond to feedback
• practical limitations of RAD

Strong benefits usually come from iteration and prototyping. Strong drawbacks usually come from the extra demands that RAD places on users, coordination or documentation.

Step-by-Step Reasoning

Benefit 1: faster production of working versions

RAD focuses on quick development of prototypes and partial working systems. Compared with waterfall, where much more time may be spent finishing earlier stages before a working system appears, RAD can produce something usable sooner.

Benefit 2: feedback and changes happen earlier

Because users see prototypes early, they can comment sooner. If something is wrong or missing, it can be changed in the next iteration. In waterfall, problems may be noticed later, after more of the system has already been developed.

Drawback: continual user involvement is needed

RAD depends heavily on feedback from users. If users are unavailable, too busy, or inconsistent in what they ask for, the process becomes harder to manage. This is a common drawback compared with waterfall, which can operate with less frequent user contact once requirements are documented.

Key Takeaways

• RAD is usually better for speed and flexibility.
• Waterfall is usually more rigid and sequential.
• Comparing models means linking each point directly to how the model works.
• Benefits of RAD usually come from iteration and user feedback.

Common Mistakes

• Giving features of RAD instead of benefits compared with waterfall.
• Repeating the same idea twice, for example saying "faster" and "quicker" as two separate benefits.
• Giving a drawback that is actually a benefit.
• Forgetting that the comparison is with waterfall.

Things to Be Careful About

• Make sure the two benefits are distinct.
• A valid drawback should be something practical, not just a vague negative statement.
• Keep each point short and focused because the mark allocation is only three marks.
• If you mention user feedback as a benefit, explain why it helps: it allows early changes and improves fit to requirements.