Describe prototyping types (evolutionary, throwaway)

System Life‑Cycle – Prototyping Types (Cambridge AS/A Level IT 9626)

1. The complete system life‑cycle (Topic 16)

The Cambridge syllabus defines the life‑cycle as a series of **phases**. Prototyping is a design‑stage technique that sits inside the Design phase.

2. Where prototyping fits

• Occurs after the **Analysis** phase (once a preliminary specification exists) and before full **Implementation**.
• Provides a tangible artefact that users can interact with, allowing requirements to be clarified, validated and prioritised.
• Results feed directly into:
  • Testing – acceptance testing of the prototype.
  • Deployment – informs training needs and rollout planning.
  • Maintenance & Evaluation – highlights potential technical debt early.
• Because prototyping influences schedule, risk and resources, it must be reflected in the **Project Management** work‑package (Topic 15).

3. Requirements analysis (Topic 16 – AO1/AO2)

3.1 Elicitation techniques

• Interviews & questionnaires
• Joint Application Development (JAD) sessions
• Work‑shops & focus groups
• Observation & shadowing
• Use‑case & user‑story writing
• Document analysis (existing system documentation, policy manuals)

3.2 Stakeholder identification & impact analysis

• Primary users – those who will operate the system daily.
• Secondary users – occasional users, managers, external partners.
• Project sponsor – provides funding and strategic direction.
• Technical staff – developers, DBAs, network engineers.
• Impact analysis – assess how each stakeholder group will be affected by the system (process changes, training needs, security responsibilities).

4. Prototyping approaches

4.1 Evolutionary Prototyping

The prototype is a **working baseline** that is continuously refined until it becomes the final system.

1. Initial prototype: develop a minimal but functional version covering core functions.
2. User review: demonstrate to users, record feedback in a structured feedback log.
3. Refine & extend: add missing features, improve usability, fix defects.
4. Repeat steps 2‑3 until the prototype satisfies all agreed requirements.
5. Transition: refactor, optimise, document and formally hand over the prototype as the production system.

Key characteristics

• Never discarded – evolves into the final product.
• Suited to complex, long‑term projects where requirements are expected to change.
• Requires disciplined code management (version control, regular refactoring, coding standards).

When to choose evolutionary prototyping

• Large‑scale information systems (ERP, CRM, MIS).
• Projects with high UI/UX focus or extensive user interaction.
• Situations where early user acceptance is critical to project success.

4.2 Throwaway (Rapid) Prototyping

A quick, low‑fidelity model built **only to clarify requirements**. Once its purpose is fulfilled, it is discarded and a clean system is developed from scratch.

1. Identify unclear areas (e.g., screen layout, validation rule, report format).
2. Build a simple prototype using rapid tools (paper mock‑ups, wire‑frame software, simple HTML/CSS, or a short script).
3. Gather feedback from users and stakeholders; log comments.
4. Discard the prototype – do not reuse code or design artefacts.
5. Develop the final system using the clarified requirements.

Key characteristics

• Temporary – not intended for further development.
• Emphasises speed, low cost and rapid feedback.
• Reduces risk of building a system on misunderstood requirements.

When to choose throwaway prototyping

• Projects with a well‑defined scope but uncertain details (e.g., a new report layout).
• Time‑critical situations requiring a quick proof‑of‑concept.
• When the team wants to avoid embedding business logic in the prototype.

5. Security considerations in prototyping (Topic 5)

Security must be addressed at every stage, including the prototype.

For **throwaway** prototypes, security can be demonstrated at a conceptual level (e.g., mock‑up of login screen). For **evolutionary** prototypes, implement real controls early to avoid re‑work later.

6. Project‑management considerations (Topic 15)

• Schedule impact: allocate a dedicated prototype iteration in the Gantt chart (e.g., “Prototype 1 – build & review”, “Prototype 2 – refine”).
• Risk management: treat prototyping as a risk‑reduction activity. Record identified risks in a **prototype risk register** (see template below).
• Resources:
  • Evolutionary – developers with design and coding skills, plus a QA tester.
  • Throwaway – a rapid‑development specialist or a UI/UX designer.
• Budget: estimate prototype effort separately; include a contingency for re‑work if a throwaway prototype is discarded.

Prototype risk‑register template

7. Evaluating a prototype (AO3 – analysis & evaluation)

7.1 Evaluation checklist (applies to both approaches)

7.2 Sample evaluation questions

• Does the prototype satisfy every functional requirement listed in the specification?
• What usability problems were identified, and how severe are they?
• Has any technical debt been introduced (hard‑coded values, lack of modularity)?
• Are there security concerns that need to be addressed before moving to production?
• Would a different prototyping approach have reduced development time or cost?

7.3 Cost‑benefit example (evolutionary vs. throwaway)

Assume a 6‑month project with 1,200 person‑hours total.

Even though the evolutionary prototype requires more initial effort, the net effort is lower because it reduces later re‑work. Such calculations satisfy the AO3 requirement for cost‑benefit analysis.

8. Comparison of Evolutionary and Throwaway Prototyping

9. Practical tips for successful prototyping

• Define clear, measurable objectives for each prototype iteration (e.g., “Validate screen layout for order entry”).
• Involve end‑users (and at least one representative from each stakeholder group) from the first review.
• Record every piece of feedback in a structured feedback log and link it to specific requirement items.
• Evolutionary prototypes: use version control, enforce coding standards, schedule regular refactoring sessions, and maintain up‑to‑date documentation.
• Throwaway prototypes: keep the design simple, avoid embedding business logic, and use rapid‑development tools such as Balsamiq, Axure, or simple HTML/CSS.
• After the final evaluation, complete a **Transition checklist** confirming:
  • All requirements met
  • Security controls in place
  • Performance benchmarks achieved
  • Code quality standards satisfied (for evolutionary prototypes)
• Update the project risk register with any new risks identified during prototyping.

10. Suggested diagram