CCEA A-Level Digital Technology 2650
Systems Analysis and Development Approaches
Design, Development and Testing
Implementation and System Security
Programming
Data, Information and Data Representation
Computer Architecture and Processing Systems
System Software, Application Software and the User Interface
Web Technology and Multimedia
Networks
Databases
Artificial Intelligence, Expert Systems and Robotics
Mobile Technology, Data Mining and Cloud Computing
Individual, Social and Legal Considerations
The Development Project: Analysis and Design
The Development Project: Build, Testing and Evaluation
The Development Project: Build, Testing and Evaluation
- 10 subtopics
- 30 things to know
- A2 Unit 2
What The Development Project: Build, Testing and Evaluation covers
The Development Project: Build, Testing and Evaluation is examined in Unit A2 2, Application Development — an internally assessed coursework portfolio. It covers choosing software to develop the solution, building the solution, test data and the types of testing, carrying out and recording the testing, Documenting a strategy for system implementation, Evaluating the solution against the user requirements, identifying extensions to the system, the electronic user guide, Bringing the system into use and supporting it and documentation for the completed system.
Where it is assessed
A2 Unit 2
Application Development — an internally assessed portfolio.
Check the CCEA specification ↗The 10 subtopics
Each one has its own page.
- Choosing software to develop the solutionRapid application development tool, throwaway prototyping and evolutionary prototyping.Open →
- Building the solutionIncremental development, version control and internal comments in code.Open →
- Test data and the types of testingWhite box testing, black box testing and unit testing.Open →
- Carrying out and recording the testingRunning each test against its expected result, capturing evidence, recording a failure with its cause and the change made, re-running the fix and the tests around it, and tracing every requirement to a test.Open →
- Documenting a strategy for system implementationImplementation strategy, data transfer and fallback plan.Open →
- Evaluating the solution against the user requirementsTaking each requirement in turn with the evidence for it, reporting shortfalls honestly, gathering the client's own assessment against real tasks, and reviewing the process as well as the product.Open →
- Identifying extensions to the systemWorthwhile extension to a library system, extension that would need substantial redesign and future-proofing a design.Open →
- The electronic user guideElectronic user guide, context-sensitive help and difference between a user guide and technical documentation.Open →
- Bringing the system into use and supporting itCorrective maintenance, adaptive maintenance and service level agreement.Open →
- Documentation for the completed systemWhat is handed over with a finished system, what the technical documents must record about the data and the processing, why decisions and their reasons are written down, and the test of whether the documentation is adequate.Open →
What you need to know
Answer each one before you reveal it.
Why does the maintainability of the chosen software matter as much as its capability?
How is the choice of software justified in the documentation?
Why should the design be updated when the build departs from it?
What are internal comments in code, and what should they explain?
What should be done about a requirement that proves impossible during the build?
Why are both white box and black box testing needed?
Give normal, boundary and erroneous test data for a field holding a quantity ordered between one and fifty.
How is the test log used after the project is finished?
What is an implementation strategy?
Why must the strategy be documented rather than agreed verbally?
What should the installation section of the strategy cover?
What is evaluation in a development project?
How should the evaluation be structured?
How does the test log support the evaluation?
Why does a development project identify possible extensions?
How should an extension be described?
Why is it useful to say what an extension depends on?
Why is the guide made accessible from the user interface?
What should a user guide contain?
What is the difference between a user guide and technical documentation?
What has to be in place before a system goes live?
Why is the backup arrangement tested before going live rather than after?
Why is most of the money spent on a system spent after it is delivered?
How does documentation relate to the handover of the system?
How is testing recorded?
What documentation is delivered with a completed system?
What is white box testing?
Why is evidence captured for each test?
Why is technical documentation delivered to the client rather than kept by the developer?
Take The Development Project: Build, Testing and Evaluation further
The same content, four other ways.
Commonly confused
Pairs that lose marks when they are blurred together.
Regression testing vs Retesting a fix
Regression testing: repeating checks that already passed, to show nothing else broke. Retesting a fix: repeating the single check that failed, to show the fault is gone.
A pilot vs Running two systems side by side
A pilot: giving the new software to part of the organisation while the rest carries on as before. Running two systems side by side: having everyone doing the work twice for a period.
Evaluation vs Testing
Evaluation: a reasoned judgement of how well the agreed requirements were met. Testing: the systematic search for faults that supplies its evidence.
Questions from this topic
Each one with the model answer underneath.
- 1
On what grounds is development software chosen for a solution?
Model answer
Software is chosen on whether it can deliver the designed functionality, whether it runs on the hardware available, whether it is affordable or already licensed, whether the developer and the future maintainer can use it, and whether it produces data in the formats other systems need.
- 2
Why is the choice of software made after the design rather than before it?
Model answer
Choosing first makes the design fit the tool, so features are included because the package offers them and requirements are dropped because it does not. Designing first states what is needed, and the package is then judged against it.
- 3
When is a database package the right choice for a solution?
Model answer
A database package suits a solution whose core is storing related records and producing queries and reports from them, because the tables, forms, queries and reports are built in and the developer writes far less code.
- 4
When is a general-purpose programming language a better choice?
Model answer
A language is better where the solution needs complex processing, an unusual interface, or integration with other systems, because a database package constrains what can be built to what its own tools support.
- 5
When might a spreadsheet be an appropriate development tool?
Model answer
A spreadsheet suits a solution that is essentially calculation and modelling over a modest amount of data with a single user, and is a poor choice for anything with related records, several users, or a need for referential integrity.
- 6
What is a rapid application development tool?
Model answer
A rapid application development tool builds much of the interface and data handling automatically from the data structure, so a working version appears quickly and can be shown to the user, at the cost of less control over the detail.
What is inside Levo
Six ways to work the same material.
The Development Project: Build, Testing and Evaluation revision questions
- What does The Development Project: Build, Testing and Evaluation cover in CCEA A-Level Digital Technology?
- 10 subtopics: choosing software to develop the solution, building the solution, test data and the types of testing, carrying out and recording the testing, documenting a strategy for system implementation, evaluating the solution against the user requirements, identifying extensions to the system, the electronic user guide, bringing the system into use and supporting it and documentation for the completed system. Each one has its own page with questions and model answers.
- How is The Development Project: Build, Testing and Evaluation organised?
- By the CCEA 2650 specification, subtopic by subtopic, so it matches the order you are taught it in.
Every question in The Development Project: Build, Testing and Evaluation, on a schedule.
Attempt a question from memory, write the correct version, then attempt it again. Levo records the jump between your first attempt and your last, and brings each question back on the day you are due to forget it.
Or £46 a year, about £3.83 a month. Cancel anytime.