Key term
CCEA A-Level Software Systems Development CL4
Software and the Development Environment
Topic overviewSystems software and application softwareThe operating system and file managementSource code filesBinary, object and executable filesCompilers, interpreters and the build processXML files and structured dataUtility software and managing files on diskThe integrated development environmentObject oriented development platformsOpen source software and licensing
Defining Data: Types, Variables and Classes
Topic overviewPrimitive types and their storageReference types, objects and nullDeclaring variables, scope and lifetimeType casting and conversionArithmetic operators and expressionsRelational and logical operatorsOperator precedence and evaluation orderObjects as occurrences of a classAbstract, base and inherited classesAttributes and the properties of a classStatic variables in a classInterfaces and class reusability
Program Control Structures
Topic overviewSequence and the order of executionMethods and passing control between themSelection with IF and IF ELSENested IF and multi-way selectionThe switch statementCount-controlled repetition with FORConditional repetition with WHILE and DO WHILENested loops and tracing iterationsBreaking out of loops and avoiding infinite loopsChoosing and evaluating control structures
Objects, Classes and Data Structures
Topic overviewConstructors and creating objectsMethods, parameters and return valuesEncapsulation and access modifiersGetters, setters and validating an object's stateInheritance and the base classOverriding methods and run-time polymorphismOverloading methodsChoosing and organising data structuresStrings and string handlingStatic arrays of simple typesArrays of objects
Exception Handling and Managing Input and Output
Topic overviewWhy errors have to be trappedTypes of error and how an exception is raisedThe try and catch blockCatching more than one kind of exceptionThe finally block and releasing resourcesThrowing exceptions and writing an exception classChecked and unchecked exceptionsReading and validating input from the command lineControlling screen outputText filesBinary filesObject files and serialisation
Testing an Object Oriented Application
Topic overviewWhy an object oriented application must be testedChoosing test data: normal, boundary and erroneousWriting a test plan for a classTesting a class method by methodTesting constructors and object stateTesting inheritance and overridden methodsTesting error handling pathsDry runs and trace tablesTest harnesses, drivers and stubsRecording and interpreting test resultsEvaluating a test plan and re-testing
Graphical User Interface Objects and Events
Topic overviewGraphical user interfaces and console programsForms and their common propertiesLabels, text boxes and text areasButtons, check boxes and radio buttonsLists, combo boxes and other selection controlsProperties, methods and events of a GUI objectContainers, panels and laying out a formThe event loop and the event queueEvent handlers and registering a listenerThe event object and reading it inside a handlerButton, mouse and keyboard triggers
Multiple Forms and Linking to Files
Topic overviewWhy an application needs more than one formCreating, showing, hiding and closing a formModal and modeless formsPassing data between formsMenus, menu items and shortcutsToolbars and navigation buttonsDesigning navigation for a multi form applicationReading and writing text filesBinary files and streamsObject serialisation and object filesChoosing between text, binary and object files
Designing, Testing and Evaluating an Event Driven Application
Topic overviewStoryboards and what they showBuilding a storyboard from user requirementsPrototyping and refining a designError trapping in an event driven applicationUsing try and catch inside an event handlerValidating what a user types into a controlDesigning a test strategy for an event driven applicationTest plans and choosing test dataTesting the paths a user takes through an interfaceDocumenting and interpreting test resultsEvaluating an application against its requirementsEvaluating features, functionality and usability
Reasons for Systems Development and Systems Methodologies
Topic overviewWhy organisations initiate systems developmentAnalysis and design principles for business solutionsRoles in development and the place of the userThe purpose of a methodology and how methodologies evolvedThe waterfall modelIterative, incremental and spiral developmentRapid application developmentThe dynamic systems development methodScrumExtreme programmingPrototyping in the development processUML modelling and simple diagrams
Managing Projects
Topic overviewThe purpose of project managementProject management concepts and the project life cycleRoles and responsibilities in project managementResources needed to develop a projectEstimating effort, duration and costGantt charts and the scheduleMilestones and checkpointsNetwork diagrams and PERTFinding the critical pathFloat and how it is usedMonitoring and controlling progressManaging risk and change
Testing Strategies
Topic overviewWhy testing matters throughout the development cycleTesting at the design stageProgram and unit testingIntegration testingSystem testingWhite box testingBlack box testingNormal, boundary and erroneous test dataUser acceptance, alpha and beta testingThe personnel involved in testingWhat a test plan containsBuilding a test plan for a scenario
Database Concepts and Entity Relationship Modelling
Topic overviewWhat a database is and why one is usedDatabase terminology: fields, records and keysThe relational modelThe hierarchical modelThe network modelEntities and attributes in an ER modelRelationships and their degreeBuilding an ER model for a problemFrom ER model to a working designComparing the three database models
Normalisation and Structured Query Language
Topic overviewWhy data is normalisedUn-normalised data and repeating groupsFirst normal formSecond normal formThird normal formWorking a full normalisation throughThe advantages and limits of normalisationThe principles of SQLSQL commands for defining and changing dataSQL statements for retrieving dataJoining tables and grouping results
Project Management and the Systems Approach in Practice
Topic overviewBreaking a development into tasks and deliverablesEstimating durations, effort and dependenciesDocumenting the plan as a Gantt chartWorking out the critical path and floatMilestones, reviews and user sign-off pointsPlanning people, resources and skillsBuilding a plan capable of reflecting changeRecording progress against the planUpdating the plan to reflect slippageRecording change requests and versions of the planEvaluating different approaches to a business problemSelecting and justifying a specific approach
Defining Requirements and Documenting the Design
Topic overviewEliciting requirements from the userWriting functional requirementsWriting non-functional requirementsSpecifying the software and hardware the solution needsProducing and agreeing the user requirements specificationDesigning the data model and the tablesDesigning the inputs, the screens and the navigationDesigning the outputs and the reportsDocumenting the processes and the logic of the solutionTesting the design against the desired user outcomesPresenting the design and the solution using appropriate media
Building a Desktop Solution with a Database
Topic overviewApplying relational techniques to a real solutionChoosing the database and the development toolConnecting the application to the databaseData adaptorsData setsData commands and parameterised queriesBinding the database to the interfaceMultiple forms and navigationSaving changes and protecting the dataTesting and documenting the built solution
Testing and Evaluating the Solution
Topic overviewPlanning the testing of the finished solutionChoosing test data: normal, boundary and erroneousTesting validation and error handlingTesting the database and its queriesTesting the user interface and the navigationTesting the whole solution and testing with the userDocumenting test outcomes as evidenceDiagnosing failures and retestingEvaluating the test proceduresEvaluating the solution against the user requirementsEvaluating delivery against the project planEvaluating your own performance on the development
Project Management and the Systems Approach in Practice
- 12 subtopics
- 36 things to know
- A2 Unit 2
What Project Management and the Systems Approach in Practice covers
Project Management and the Systems Approach in Practice is examined in Unit A2 2, Implementing Solutions — an internally assessed portfolio. It covers breaking a development into tasks and deliverables, estimating durations, effort and dependencies, documenting the plan as a Gantt chart, working out the critical path and float, milestones, reviews and user sign-off points, planning people, resources and skills, building a plan capable of reflecting change, recording progress against the plan, updating the plan to reflect slippage, recording change requests and versions of the plan, evaluating different approaches to a business problem and selecting and justifying a specific approach.
Where it is assessed
A2 Unit 2
Implementing Solutions — an internally assessed portfolio.
Check the CCEA specification ↗The 12 subtopics
Each one has its own page.
- Breaking a development into tasks and deliverablesDeliverable in a development plan, term scope and one advantage of numbering the tasks in a project plan.Open →
- Estimating durations, effort and dependenciesDifference between the effort a task needs and its duration, dependency between two tasks and genuine dependency inside a database-driven solution.Open →
- Documenting the plan as a Gantt chartLaying tasks against a timeline, showing durations, dependencies and milestones, marking progress against today's date, and what the chart shows about a project that is running late.Open →
- Working out the critical path and floatFinding the longest chain of dependent tasks, what total float and free float each mean, why a task on the critical path has none, and what happens when a task overruns its float.Open →
- Milestones, reviews and user sign-off pointsMilestone in a development plan, three sensible milestones for a database-driven desktop development and milestone and a deliverable.Open →
- Planning people, resources and skillsResource levelling and what is meant by a resource constraint.Open →
- Building a plan capable of reflecting changeBaseline plan, rolling wave plan and scope creep.Open →
- Recording progress against the planProgress log and what variance means in a project plan.Open →
- Updating the plan to reflect slippageWhat crashing a plan means, what fast tracking a plan involves and recorded every time the plan is changed.Open →
- Recording change requests and versions of the planChange request and what a change log contains.Open →
- Evaluating different approaches to a business problemFive criteria to set before comparing candidate approaches and what time-boxing contributes to an approach.Open →
- Selecting and justifying a specific approachMatching an approach to the client, the requirements and the time available, why short iterations suit an uncertain user, the risks prototyping carries, and recording the reasons for the choice.Open →
What you need to know
Answer each one before you reveal it.
Your recallNot started
Key term
What makes a task in a plan too large, what should every task state, and what is a deliverable?
Key term
What is the difference between the effort a task needs and its duration?
Key term
What does the horizontal bar for a task on a Gantt chart tell you?
Key term
How is the critical path through a project plan identified?
Key term
Define a milestone in a development plan.
Key term
Which resources besides people have to be planned for a desktop development?
Key term
What does it mean for a project plan to be capable of reflecting change?
Key term
Define a progress log.
Key term
Which three things does the developer update when a task overruns?
Key term
Define a change request.
Evaluation
Why is listing the advantages of the chosen approach not a justification?
Key term
What is the first thing a developer does when turning an agreed business problem into a project plan?
Key term
A task needs 12 hours of work and the developer can give it 3 hours a day. What duration should go in the plan?
Key term
How are dependencies shown on a Gantt chart?
Key term
A plan has two chains between the same two points, one of 20 days and one of 14 days. Which chain is critical?
Key term
Why is a milestone given no duration?
Key term
Why is access to the user treated as a scheduled resource?
Key term
Why is a plan drawn up at the start certain to need changing?
Key term
Why is the actual duration of every task recorded?
Key term
Why must the plan be updated as soon as slippage is known?
Key term
What should a change request record contain?
Evaluation
What does it mean to evaluate different approaches to a business problem?
Key term
How is a rejected approach dealt with in the justification?
Process
How does a work breakdown structure help when planning a database-driven desktop solution?
Key term
Why do estimates for a first development usually turn out to be too short?
Key term
How is progress recorded on a Gantt chart while the development is under way?
Key term
What does it mean to say a task has zero float?
Key term
Name three sensible milestones for a database-driven desktop development.
Key term
Define resource levelling.
Key term
How does keeping tasks short make a plan easier to change?
Key term
Explain what variance means in a project plan.
Key term
A task with six days of float slips by two days. What happens to the finish date?
Key term
Why is a change request assessed for impact before it is accepted?
Key term
Which kind of approach suits a problem whose requirements are fully known and unlikely to change?
Key term
What should the developer do if the chosen approach proves wrong halfway through?
Take Project Management and the Systems Approach in Practice further
The same content, four other ways.
Commonly confused
Pairs that lose marks when they are blurred together.
Parallel tasks vs Dependent tasks
Parallel tasks: jobs that may be scheduled across the same days. Dependent tasks: jobs that must run one after the other.
Questions from this topic
Each one with the model answer underneath.
- 1
What is the first thing a developer does when turning an agreed business problem into a project plan?
Model answer
The developer breaks the whole development into separate tasks, each of which produces something identifiable.
- 2
How does a work breakdown structure help when planning a database-driven desktop solution?
Model answer
A work breakdown structure splits the development into smaller and smaller pieces. Each piece ends up small enough for one person to estimate and finish.
- 3
What makes a task in a project plan too large to be useful?
Model answer
A task is too large when progress inside it cannot be judged, so the plan reports the same task as in progress for weeks.
- 4
Besides its name, give two things every task in a project plan should state.
Model answer
Every task should state its expected duration and the person responsible for carrying it out.
- 5
Define a deliverable in a development plan.
Model answer
A deliverable is a tangible product of a task, such as an agreed requirements document, an ER diagram or a working form.
- 6
Why is each task given a completion criterion?
Model answer
A completion criterion states what must exist before the task counts as finished. Progress cannot then be claimed on work that is still open.
What is inside Levo
Six ways to work the same material.
Project Management and the Systems Approach in Practice revision questions
- What does Project Management and the Systems Approach in Practice cover in CCEA A-Level Software Systems Development?
- 12 subtopics: breaking a development into tasks and deliverables, estimating durations, effort and dependencies, documenting the plan as a gantt chart, working out the critical path and float, milestones, reviews and user sign-off points, planning people, resources and skills, building a plan capable of reflecting change, recording progress against the plan, updating the plan to reflect slippage, recording change requests and versions of the plan, evaluating different approaches to a business problem and selecting and justifying a specific approach. Each one has its own page with questions and model answers.
- How is Project Management and the Systems Approach in Practice organised?
- By the CCEA CL4 specification, subtopic by subtopic, so it matches the order you are taught it in.
Every question in Project Management and the Systems Approach in Practice, 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.