Upload
dinhthien
View
213
Download
0
Embed Size (px)
Citation preview
- i -
An Adaptive Computer Based Learning for Key
Stage 2 Mathematics
Andrew Callander Computing BSc
2006/2007
The candidate confirms that the work submitted is their own and the appropriate credit has been
given where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be
considered as plagiarism.
(Signature of student)________________________________
- i -
Project summary
Recently the use of computers in schools has become more and more important. This is so
that future generations are computer literate and comfortable learning new computing skills.
Another recent subject of interest is the development of adaptive systems. This is a system
that changes its output and performance for individual users. This has a promising place as
children need not only constant attention but also individual treatment as each one is unique.
The project looks at applying different learning styles to a computer based learning system for
Primary schools that will adapt to fit a user individual learning style. The project aims to look
into the following to do this
1. Background research into Learning Styles, Adaptive Systems and teaching with computers in
Primary School.
2. Design of a prototype to demonstrate he potential of this system for suggesting future exercise
based on a users learning style.
3. Implementing the prototype designed.
4. Evaluation of the final prototype based on results gained and user opinions.
- ii -
Acknowledgements This project would not have been possible without input and support from others. This section is my
thanks to them.
I would like to thank my supervisor Andy Bulpitt for this guidance and support throughout the project.
I would also like to thank Vania Dimitrova for her feedback and resources provided on adaptive
systems. Without the positive comments and criticisms this project would not have reached
completion.
This project would also not have been possible without the expertise of Nick Greenop and the
feedback from the teachers and teaching assistants from Woodslea Primary School (present and past).
My family also deserve praise for helping me stay in University and keeping me working all this time.
I would also like to thank my housemates and course mates for their support throughout my time at
University without whom I may not have stayed the course.
- iii -
Contents Page
Chapter 1: Introduction ....................................................... 1
1.1 Project Aim ...................................................................................................................... 1
1.2 Minimum Requirements................................................................................................... 1
1.3 Possible Extensions .......................................................................................................... 1
1.4 Deliverables...................................................................................................................... 1
1.5 Project Schedule............................................................................................................... 2
1.6 Problem Area.................................................................................................................... 2
Chapter 2: Project Research................................................ 3
2.1 Learning Styles and Computer Aided Learning............................................................... 3
2.2 User-Adaptive Systems .................................................................................................... 5
2.3 Maths Curriculum ............................................................................................................ 7
2.4 Summary .......................................................................................................................... 8
Chapter 3: Methodology....................................................... 9
3.1 Waterfall Approach .......................................................................................................... 9
3.2 Prototyping ..................................................................................................................... 10
3.3 Chosen Methodology ..................................................................................................... 11
3.4 Integration of Methodology ........................................................................................... 12
Chapter 4: Needs Analysis and Requirements ................. 14
4.1 Techniques ..................................................................................................................... 14
4.2 MuSCoW Analysis......................................................................................................... 16
4.2.1 Must Haves.............................................................................................................. 16
4.2.2 Should Haves........................................................................................................... 16
4.2.3 Could Haves ............................................................................................................ 16
4.2.4 Won’t Haves............................................................................................................ 16
4.3 Functional Requirements................................................................................................ 17
4.3.1 Essential Functional Requirements ......................................................................... 17
4.3.2 Possible Functional Requirements .......................................................................... 17
4.4 Non-Functional Requirements ....................................................................................... 17
4.4.1 Essential Non-Functional Requirements................................................................. 17
4.4.2 Possible Non-Functional Requirements .................................................................. 17
4.5 Business Rules................................................................................................................ 17
4.6 Summary ........................................................................................................................ 18
Chapter 5: System Design .................................................. 19
5.1 System Content .............................................................................................................. 19
5.2 Navigational Structure.................................................................................................... 20
5.3 Visual Design ................................................................................................................. 21
5.4 Technical Design............................................................................................................ 22
5.4.1 Website.................................................................................................................... 22
5.4.2 Database .................................................................................................................. 23
5.5 Summary ........................................................................................................................ 24
Chapter 6: System Implementation................................... 25
6.1 First Iteration Prototype ................................................................................................. 25
6.2 Second Iteration Prototype ............................................................................................. 27
6.3 Third Iteration Prototype ................................................................................................ 30
- iv -
6.4 Summary ........................................................................................................................ 30
Chapter 7: Project Evaluation ........................................... 31
7.1 Comparisons to Project Aim and Requirements ............................................................ 31
7.2 Teachers Feedback ......................................................................................................... 32
7.3 Potential Future Additions ............................................................................................. 32
7.4 Evaluation of Project Stages .......................................................................................... 32
7.5 Conclusion...................................................................................................................... 33
References
Appendix A: Personal Experience..................................... 37
Appendix B: Schedule ........................................................ 38
Appendix C: Learning Style Tests..................................... 39
Appendix D: Subjects in Curriculum................................ 41
Appendix E: Current Software.......................................... 42
Appendix F: Example Questions ....................................... 43
- 1 -
Chapter 1: Introduction
1.1 Project Aim
To investigate the use of learning styles in teaching and assess the possibility of using these learning
styles in a Computer Aided Learning Scheme. The Project will focus on teaching basic number
manipulation in different styles. A user’s style will be assigned based on a user’s performance on set
questions. The system should also have the scope to adapt a user’s style based on their continuing
performance.
1.2 Minimum Requirements
1. An analysis of various Learning Styles developed for children and their place in Computer
Aided Learning.
2. A framework Computer Aided Learning System to demonstrate the uses of different learning
styles in teaching basic primary school number work (addition, subtraction etc).
1. Extensions to the above assigning users a learning style based on the results of a learning
styles test
1.3 Possible Extensions
1. Automatic assigning of tasks to suit the users chosen learning style once the test has been
completed
2. Constant updating of users learning style as they continue to use the system
1.4 Deliverables
There will be two deliverables for this project
1. Project Report
2. A prototype of the system providing basic functionality
- 2 -
1.5 Project Schedule
A project schedule was drawn up using Microsoft Project. This is shown in Appendix B. The schedule
was kept to in the early stages but as the implementation started problems were encountered. Getting
feedback from the Teachers proved more difficult that expected. As such coding was slowed down as
prototypes waited for evaluation. All work was caught up with eventually and the project reached all
its minimum aims in time.
1.6 Problem Area
The project spans three different areas of research. It looks at learning styles, adaptive computer based
learning and the teaching of mathematics to Primary Schools children.
Learning styles have been researched for decades with no real practical use having been found yet.
The importance of learning has been overlooked for the importance of working. Some jobs now
require a person to take Belbin personality test to establish their place in the team and their generic
personality. Whilst some schools have started looking into profiling children to optimise their learning
there is still a lot or progress to be made.
Adaptive systems are one of the current up and coming ideas in Computing and the research being
done increases the potential for these to advance even further in the coming years. Their use in
learning has become very popular with lots of systems taking their users different needs into account
and supply a variety of services to suit all needs.
The subject matter in Primary School learning is basic and simple to explain to those already in the
know, but conveying this knowledge to children can prove more of a challenge. This is hopefully
where the role of learning styles and curriculum will prove most useful.
I will look relatively briefly into each of these areas as I cannot gain an in-depth knowledge over any
of them in the time available to me. I will have to however research enough to not only justify my
project but also to complete it.
- 3 -
Chapter 2: Project Research
2.1 Learning Styles and Computer Aided Learning
“Learning is a relatively permanent change in behavioural potentiality that occurs as a result of
reinforced practice “(Kimble, 1967).
There is often a lot of focus given in schools on the way that subjects are taught and less on the way
that students learn (Askew 1997). This has not been such a big issue in the past as there was never a
real solution to offering individual programmes for learning in schools. The class size and varied
individuals in such an environment mean that a teacher could not cater to every different learning
preference. The introduction of computers has changed this but as with most technological advances
society has not yet caught up yet. With a reported 1 million primary school children using e-learning
in class each day (Cabinet Office 2007) the fantasy of individual learning plans is becoming a reality.
A teacher does not have one approach to teaching a child. It is their ability to adapt that gives them
their use; otherwise worksheets and curriculums could easily remove the need for a teacher as
anything other than a supervisor and law enforcer. Teachers vary the material and methods they use
for each individual case. This is to adapt to a child’s personal learning style. Whilst it is not practical
to completely replace the role of a teacher with ICT it has the potential to ease the workload by not
only determining a child’s learning style, but recommending work to be done that would benefit those
in who learn best in a specific learning style. As such this would not be a replacement of a way of
learning but yet another tool to aid in a child’s education, like the interactive whiteboard or a logo
floor turtle.
“Learning styles are complex and frequently misunderstood – they encompass how learners process
information, their sensory preferences and the approaches learners adopt for particular tasks.”(BECTA
2005)
BECTA is the British Educational Communications and Technology Agency. They deal with the UK
Governments ICT strategies and future projects. They give advice on how ICT can be better used in
education. Their report on “Supporting Learning and Teaching in Primary Schools” (2006)
specifically mentions the possibilities of adaptability to different learning styles.
The use of Learning Style profiling is not a new one in schools. An Ofsted report by the government
into Easterside Primary School in Middlesbrough commented on the schools “exciting range of
- 4 -
teaching and learning styles that challenges pupils’ concepts and extends their knowledge and
understanding.”(Ofsted, 2004)
Studies into different learning styles have been undertaken for decades. The two main theories are
Kolb’s and Multiple Intelligences.
Kolb’s Four Learning Styles (1984) are; Concrete/Reflective, Abstract/Reflective, Abstract/Active and
Concrete/Active. These styles are used in conjunction with various teaching methods by the
Counselling and Career Development Unit at the University of Leeds to help teachers realise the
potential of varied learning styles.
The Concrete/Reflective always wants new challenges and fresh knowledge. Abstract/Reflective
learners are interested in what’s and how’s of a problem preferring a logical explanation and
representation. Abstract/Active stereotypes use a trial and error base to solve the problem and so learn
by doing and from their mistakes. Concrete/Active learners deal best in real-world situation and can
understand a problem better if it can be given some significance to their life.
Multiple Intelligence (Meir, 2002) is a theory by Pachler & Gardner. It stereotypes learners into seven
styles:
Visual/Spatial – Puzzles, Charts/Graphs, Visual Metaphors
Verbal/Linguistic – Words, Explanations, Storytelling
Logical/Mathematical – Problem Solving, Classifying/Categorizing, relationships between items
Bodily/Kinaesthetic – Hand Eye Coordination
Musical/Rhythmic – Patterns, remember things in order
Interpersonal Intelligence – Dual Perspective
Intrapersonal Intelligence – Self Analysis
Above only the aspects applicable to a computer based system are highlighted.
One of the more generic theories by Leask et al (2004) covers opposing styles and how the two sides
demonstrate the polarity between styles.
• Holistic vs. Analytical – Dealing with the problem as a whole or breaking it down into steps.
• Verbal vs. Imagery – Thinking of a problem with reasoning and facts or thinking of a situation
the problem could be applied to.
Support4learning.org.uk (2007) recommends Kolb’s Learning Styles as its introduction to although
this seems to be focused on Further Learning rather than Primary School. The styles given are not
simple enough to be applied to children of this age and this is why most examples of children’s
- 5 -
learning styles are represented by the Multiple Intelligence guidelines. Whilst the Multiple Intelligence
theory does seem to be focussed on younger learners with its kinaesthetic and tactile options it is not
as suited to Computer Aided Learning system as although a sense of moving objects around can be
achieved via machine it is still not physical which defies the point of having this learning style.
The majority of these learning styles use a questionnaire of sorts to determine a learning style. A
selection of these tests, are shown in Appendix C. These questionnaires tend to use personality based
questions rather than knowledge based ones. This is not very useful as I am looking to use
mathematical questions already in a learning style to determine a user’s preferred style. This is a more
direct approach and should simplify my task allowing it to be completed on schedule.
As none of the learning styles documented are ideal for this situation they are going to have to be used
as guidelines rather than strict rules. Rather than catering for all possible learning styles a system that
caters for those applicable only to Primary School Maths in a practical ICT would be a more useful
example of the potential for a system that provides useful learning styles.
2.2 User-Adaptive Systems
“User-adaptive systems are interactive software systems that spontaneously adapt to their individual
users, for example, to their interests or their work habits.” (Jameson, 2001)
Personalisation and User-Adaptive Systems are the current buzz-words in the AI world. Since the
popularity of Amazon ands it famous recommender system took off more and more companies are
looking to tailor their product to individuals. This is not just happening in the large commercial
companies but everything ranging from small businesses to government bodies. The NHS runs a
system to allow a patient to diagnose themselves online. Whilst it is not perfect it represents a great
step forwards in giving users interactive results suited to their exact situation. The degree to which a
system’s adaptability or its personalisation is more than just an interactive system or user simple user
preferences is debatable. They do not need to be automatic (i.e. a user may still have to provide input
to acknowledge the change) all they have to do is change the working environment so it takes into
account some feature of the user.
Existing Web-based learning systems use different types of adaptation techniques (Brusilovsky,
1996).These techniques vary from the adaptability of presentation, to the actual content. The
presentation can change by varying the navigation options. My system will be a Curriculum
Sequencing system. This is where the system provides the student with the most suitable path through
- 6 -
the material by altering the sequence the material (examples, questions, problems etc.) is presented in
is individually designed for premium learning.
“A student model is any information which a teaching program has which is specific to the particular
student being taught.” (Tim O'Shea,1983)
This is essentially what will allow an adaptive system to know how best to suit a users needs. If they
have knowledge of a users past use of the system then this can be put to use in determining a users
preferences and personalising the future settings accordingly. Whilst every student will be different in
their learning style and preferences most should be able to fit into or between certain set generic
models.
Adaptation on the whole relies on user modelling. These can be very simple stereotypes that work on
very rough data; others involve many user models that overlay. Weber (1996) points out that, simple
types of curriculum sequencing can be “based on (typically rough) stereotype user models”. This
would be the aim of my project as developing detailed user models for this project would not be
achievable in the time allocated. Weber does however point out that it is the most advanced AI
techniques that create complex user models that are used in intelligent tutoring systems (ITS).
One of the current criticisms of this adaptive technology in tutoring is the way that it can give too
much help. This according to Carole Beale (ISI researcher) is that students can “game” the system
(2006). This idea is that hints and tips are given to readily and so users start to cheat and use the hints
to answer the question rather than their knowledge. This also applies to multiple choice tests as
students can learn the answers form simple guessing and then reuse them. This is not the type of
learning that will help them in the outside world and so must be avoided. This is not one of the major
problems with my proposed prototype but it is still something to be considered. I will more than likely
need to have multiple choice tests for the initial assignment of learning styles but after this I will try
and avoid them so as to provide a more productive learning environment.
There is the potential for a recommender system in this system but I will not look into this at this time.
This would be implemented by having users recommending exercises they found useful to others in
the same learning style bracket as them. This however involves lots of input to provide a variety of
exercises and users to demonstrate this. Instead I will focus on the stereotype method so that users are
simple entities making the system as a whole easier to demonstrate future potential.
Weighting of the learning styles is going to be most efficient way of demonstrating the potential of
this system. In doing this I will alter the values for each style as a user answers a question. This will
- 7 -
result in the values incrementing as the user becomes more efficient at a topic and the values
decreasing as the user learns new skills for a fresh topic. It will also stop the user’s preferred learning
style being static as these values will be constantly changing. This will cater well to the fact that if a
student is failing to understand a concept in one learning style a change of tact could shed light on the
new subject for them.
There are several commercial and government funded systems out there that deal with adaptive
learning. One of the most prominent from my research is Carnegie Learning’s Cognitive Tutor. I
decided to look at this to see what they incorporated into their system and find their strengths and
weaknesses. As this is a commercial product I was unable to get full details on the working of the
system however.
Cognitive Tutor “monitors the status of the student’s knowledge on a moment-by-moment basis and
tailors course material, based on these continual assessments. IT uses a cognitive model based on John
Andersons ACT theory of human cognition. This is a well renowned theory of how we learn based on
over 20 years of research. Cognitive Tutor constitutes several small systems that offer features from
skills tracking to hints & help when the student is deemed to be in need of it.
Obviously this is all far beyond the scope of this project and I cannot hope to recreate this quality of
system. But it did gain some insights into what I would need to include my system and helped shape
the system.
2.3 Maths Curriculum
The curriculum set in the UK conforms to some very tight guidelines and so is something that has to
be taken into account if this system is designed for a Primary School. The government Education
Standards website details the subjects to be covered and the level at which it should be taught. I have
summarised the Subjects in Appendix D. The area the prototype will cover was an important decision.
It will change the system in how I decide to implement the prototype and also the learning styles I can
incorporate.
To research the real life situation I spoke to the teachers who would benefit from such a system and
also Nick Greenop who is the ICT supervisor for the schools on the Wirral. The teachers’ views were
useful but were too specific to base a system on. They related only to one class in one school. Mr
Greenop’s experience however in organising the systems over a whole county gave a much more
general view in what the current situation is and what the potential for this system is in the future.
- 8 -
Mr Greenop highlighted the fact that every school varies its ICT usage as there is currently no strong
guidance on this area. Teachers are recommended to use computers in their lesson plans but the degree
to which they do is not set. He also pointed out that the general consensus is that less input is a good
thing as they do not have time to input lots of data. It was however highlighted that this could change
in the future as teachers’ training with computers improves.
Websites are currently the favoured vessel for these systems as the web is a platform independent
system on the whole that can theoretically be used anywhere at any time. The BBC Bitesize website
was highlighted as one of the most popular ones amongst teachers and pupils alike.
When asked what the main advantages and disadvantages of Computer Aided Learning over more
traditional methods Mr Greenop gave a few. He pointed out that the ability to provide direct feedback
was the main advantage as it allowed the teachers and students to assess progress and gave
encouragement. This is something that will have to be considered when the output is being generated
in the prototype. He also highlighted the problems with “gaming” the system and simply guessing the
answers on multiple choice exercises.
I was also given a list of the most popular software used in schools on the Wirral. Some were
government funded others commercial. They varied from game based systems to plain worksheets
designed for easy transition to interactive whiteboards. More details about these are included in
Appendix E.
From this I looked at the current market of Computer Aided Learning for Maths in Primary Schools.
This was not so that I could contend with them but simply so I could see what the expectations are and
the general style and basic feedback given from these systems.
Maths Whiz 1 is a large system that includes over 120 exercises. One of the main features added real
worth to my research was the timed element for the exercises. This gives the potential to not only
mark if a question is answered correctly but also how quickly it was done. This is seen as potential
addition to my prototype so that the weighting of a learning style could be modified based on this extra
factor.
2.4 Summary
Much was learned from this research and despite the variety of it as much as possible must be
implemented into the system design to justify my final prototype.
- 9 -
Chapter 3: Methodology
For any project be it a relatively small one such as this or a major companies new investment,
guidelines are needed to define the path the project will take. This will help to ensure that the project
follows a schedule and set goals. These stages will prove very helpful but only if the correct
methodology is chosen not only for the project but also the time limits.
I shall look at two major methodologies that present opposing views to how a project should be
approached and planned. The Waterfall model presents a structured inflexible series of stages and the
Prototyping method that represents and iterative informal approach to the planning.
3.1 Waterfall Approach
• Requirements Analysis
• Specification
• Design
• Implementation
• Testing
• Operation Maintenance
Above is a basic outline of the Waterfall Model (Sametinger, 1997). This was originally devised by
W.W.Royce in 1970 as a sequential software development tool. It works by following each of these
steps in order and without progressing until one step is completed.
So the first step would be to discover the requirements of a system by gathering data as to what
previous systems do and what the new one is expected to do. This can be done by interviews with
users and shareholders or by observing the current system in practice. After this a specification can be
drawn up to detail what function the final system will perform. This will involve decisions such as the
platform and minimum requirements to be used as the basis. Once this is completed the system can be
designed so that it covers all the points raised in the specification. The implementation, or coding in
this case then takes place based on the previous steps recommendations. Once all the specifications
have been completed to the design the system is tested against the standards set. The only remaining
step is to provide maintenance and ensure that the system continues to work as it was intended.
The obvious flaw with all of this is the rigidity of the model. This is sometimes also seen as the major
advantage of the model. If these deadlines are set and maintained then the project should run smoothly
and as long as each step is completed perfectly the final product should also be perfect. This is the
earliest model and more recent ones often include a step whereby if the testing shows an unsatisfactory
- 10 -
outcome or the final product is not what the user wants the process can be restarted from the
specifications stage with these flaws taken into consideration.
Royce himself realised the flaws in this original model and modified it to include the iteration after
testing into what he called a Spiral Model. Despite his observations over the shortcomings of the
original model it is still widely used today as it provides rigid guidelines that can be followed with
little ambiguity.
I do not however feel that this would be the most appropriate method to follow for this system. It
would rely far too much on the first run being near perfect and due to the time constraints and
deadlines for other tasks an iterative approach could provide a better way of assessing the potential of
this system as once a basic version was made it could then be improved on in smaller steps to get as
much potential demonstrated as possible.
3.2 Prototyping
The main feature of this process is the quick creation of a model that can then be changed and added
to, based on the constant testing. The initial stages of requirements analysis and design are still
required but these are not set in stone and so are not only allowed to change but expected to. This
expectance helps to avoid the difficulties and costs of changing the final system as all of these have
been considered in advance.
There are two main forms of prototyping that are widely used. These are Throwaway prototyping and
Evolutionary prototyping. Both of these are fairly generic methods and vary from case to case.
Throwaway prototyping involves creating a model that will not have anything in common technically
with the final working system but will instead show what the system will provide. The priority here is
not the quality but the speed with which the prototype is developed. It is only designed to show what
requirements the final system will fulfil not how they will be.
The design is used to refine the requirements and once this has been done this prototype is discarded.
So all that is taken from this methodology is the requirements which by this point should be as
accurate as possible as the users and shareholders have worked over them in detail with the system
designers. This point is highlighted in Overmyer’s work into Rapid Prototyping.
“Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of
evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate
- 11 -
specification of requirements and the subsequent construction of a valid and usable system from the
user's perspective via conventional software development models.” (Overmyer, 1991)
The form of this prototype can vary in quality. There can be actually GUI’s designed that work with
dummy functionality. This would allow the user to navigate a system that seems to be a fully working
version so they can assess the functions and usability without the actual coding being done. At the
other end of the scale is storyboarding that can remove computers from the equation altogether. This
involves just documenting the different screens planned to be shown throughout the system. These can
then be added to or removed by the users depending on what they want.
Evolutionary prototyping is opposed to Throwaway in that it aims to create a better prototype that has
the potential to be built on and used later in the project. It is still originally created to demonstrate the
future plans and potential for the system. However the way it is made is so that is going to be more
robust and detailed so it can be built on and “evolve” as the project grows.
The main advantage here is that development of a system need never stop. As the prototype is being
constantly assessed the input from users and shareholders can forever be shaping the requirements and
so the system will suited to the users changing needs.
The disadvantages of both these prototyping approaches are that the goals of the project can be lost
along the way. This happens because set requirements are not there to give specific deadlines. There is
also a view that systems based on prototypes are often poorly engineered as they have been designed
around such a simple idea that does not transfer well to a larger scenario.
3.3 Chosen Methodology
The methodology chosen does not shape the project. The methodology is chosen based on the project
type. As such I have looked at the project outline and the above two methodologies and decided that
an evolutionary prototype approach would prove best given the aims and deadlines.
The fact that the projects aim is to assess the potential for a system means that rigid guidelines are not
likely to be productive. Instead this is likely to put too much pressure on the completion of a system.
Alternatively the prototype method allows for a more ad hoc series of events. This will allow for
investigation into how much can be done in the limited time. Also it allows for the system to change to
the recommendations of the users. I have some good contacts with an IT specialist in schools and
teachers, so I can keep getting their input to shape the full functionality.
- 12 -
As I have already decided to use a web based system for the implementation the prototype approach
also compliments this; “It has been found that prototyping is very effective in the analysis and design
of on-line systems” (Crinnion, 1991)
Also as the system is never planned to be a complete working system the prototype approach means
that my only aim would be to get as many iterations and additions to the project as possible. This
would mean that it represents the desires of the people who would show the main interest in the
system (teachers).
3.4 Integration of Methodology
To deploy this method with my project there are four distinct stages that need to be completed. These
are detailed further in work by Avison et al (2003). I will need to analyse the current environment and
the user’s fundamental needs and requirements. I will need to develop a prototype that conforms to
these needs on a basic level. I will then have to evaluate the prototype and modify the prototype based
on results from this several times. Finally a fully working system can be made based on the prototype.
The analysis stage will involve further discussion with teachers and my ICT expert in schools. From
this I will look at what learning styles would be useful to incorporate and the material that could be
presented within the system. The teachers can help to suggest what material should be covered and in
what styles, whereas Mr Greenop could help to suggest what could be realistically represented and in
what styles. These requirements could be set and put into a MuSCoW analysis to show what the
system Must Have, Should Have, Could Have and Won’t Have.
I can also look at the current systems that are present and what they provide but I do feel that due to
the time constraints I will not be able to recreate anything near their level of interactivity in my
prototype as games are notoriously difficult to program well.
The next stage will be the development of the prototype. This will be primarily based on the
requirements derived from the Must Have section. This will ensure that it meets the minimum
requirements set.
The next stage is the evaluation and modification of this prototype. This will help to build on the
minimum requirements and add to the functionality of the prototype. This will be based on what the
teachers deem as useful additions to the system and also what fits into the projects specification.
- 13 -
The final stage of a typical prototype methodology is the creation of a final system based on the
success of the prototypes. This however will not be relevant to my project as I do not expect to
complete a final system. Instead I will strive to achieve the most complete prototype possible.
- 14 -
Chapter 4: Needs Analysis and Requirements
“Software requirements express the needs and constraints placed on a software product that contribute
to the solution of some real-world problem.”(Kotonya, 2000)
A good system is not just a system that works. It also needs to fit the requirements set by the users and
stakeholders. These requirements are the basis on which the whole system is to be made. They are the
reason that the system is required in the first place. So by understanding the old system we can
engineer a new system that not only provides new features but covers the ones already being
performed and possibly improves on them.
4.1 Techniques
One of the main methods to get information about the current system and the users desires from the
new one is to interview the users and ask them what they see as shortfalls of the current system and
what extra tasks they would like the new one to perform.
In this situation the major stakeholders and the children using the system and the teacher’s
incorporating it into their lesson plans. Unfortunately gaining access to children inside school is
becoming increasingly difficulty with new laws being passed. I enquired into the possibility of
interviewing or even having my ideas presented to children in two schools but both had to refuse due
to these laws.
I was however able to get some time to talk to 7 teachers and teacher’s assistants from 3 different
schools and ask them their views on the project and its aims, The majority of the staff saw the
potential for this system although some were wary of the technological risks associated with any
computer based system. They agreed that students needed to receive their own personalised approach
to education and this was often not available on computers.
The majority also showed doubt over the usefulness of stereotyping the children as they felt no simple
test could account for all the diverse behavioural aspects of a child. One Teaching Assistant mentioned
the possibility of assigning learning styles based on a teacher’s judgement solely. They also pointed
out that there would be a need for the system to constantly adapt to the child who grows and changes
constantly also. This would involve the questions modifying the students learning style as well.
- 15 -
Another method of requirements analysis is to look at the outputs and inputs of the current system.
This is done I this situation by looking at exercise sheets and teacher training material to help
understand how they deal with a child’s learning. I took some exercises from the standards website
(Appendix F) and the learning styles course content for a primary school teacher. I took the question
style and wording from the exercises and the learning styles and approaches from the course content
into consideration for my system.
Prototypes are often used to show the potential. As my system was not developed enough to show a
working prototype I instead demonstrated the potential by showing them other learning style tests and
how they could be adapted to their situation. As however the system would be shown to these people
at every possible opportunity their views on the prototype would constantly be received.
Figure A
<<extends>
Register / Login
Determine Learning
Style
Take Learning Style
Test
Answer Personalised
Questions
<<extends>
Student
- 16 -
From the interviews and documentation I was able to develop a basic use case diagram to demonstrate
the basic functions of the system that would satisfy the needs of the end users. This is by no means the
full potential of the system as there is still the option of the personalised questions updating the
learning style as well. This has been left out so the diagram shows only the most basic functions that
need be performed. This is shown above in figure A.
4.2 MuSCoW Analysis
From all of this I can not only identify what features need to be present but also their priority which
will prove very valuable upon starting implementation. The main restrictions on the Won’t Haves are
the time limit that prevents me from adding too much data to the system.
4.2.1 Must Haves
• Learning Style Test to determine at least 2 learning styles
• Ability to generate a learning style
• Questions returned based on generate learning style
4.2.2 Should Haves
• Login/Register Feature to save progress
• Feedback on test results
4.2.3 Could Haves
• Timed feature to aid assessment of test
• Teacher admin rights to allow them to modify the exercises
• Teacher admin rights to allow them access to learning style data for students
4.2.4 Won’t Haves
• Extensive coverage of Learning Styles e.g. tactile, imagery, auditory etc.
• Extensive content in terms of exercises to follow up the system.
I will now look at what the functional and non-functional requirements will be for the system will be.
Rather than being what must and should be in the system this instead looks at which aspect of the
system the feature will address. This can be the functional, which performs a specific task, or the non-
functional, which will not be a major function but merely an aspect that will glue the functions
together. They are based on the analysis completed above. I will also list possible functional and non-
functional requirements. These are not likely to be included in the prototype but should still be taken
- 17 -
into consideration for future developments. The business rules are elements that are not intrinsic to
the learning process but are required in the system.
4.3 Functional Requirements
4.3.1 Essential Functional Requirements
• A Learning Style Test designed to assess a users preferred Learning Style
• Marking of the Test to determine users preferred Learning Style
• Results from the Test to inform the user of their Learning Style
• Questions that conform to the users preferred Learning Style based on the results of the Test
4.3.2 Possible Functional Requirements
• Marking of the Questions to modify users preferred Learning Style
• Administrator rights to allow Teachers to view a students learning style
• Administrator rights to allow Teachers to add their own material to the course and form new
exercises
• Administrator rights to report results of exercises to Staff aiding their monitoring of the
student
4.4 Non-Functional Requirements
4.4.1 Essential Non-Functional Requirements
• Easy to navigate system
• Simple exercises that do not rely on complex concepts
• Uncluttered view to avoid confusion
4.4.2 Possible Non-Functional Requirements
• User friendly attractive GUI
4.5 Business Rules
• All users will need to login to use the system
• Students will register themselves for system use
• Student doe not get access to other student’s accounts
- 18 -
4.6 Summary
The requirements for the prototype have now been established through a process of data gathering
from a Primary School environment. These requirements have then been divided into not only
functional and non-functional requirements by have also been given priorities to show their
importance to the system.
- 19 -
Chapter 5: System Design
The design of a system is very important to ensuring that not only does the final system have all the
required components to demonstrate real world use, but also that it is presented in such way that the
data and features are easily accessible.
Rees (2001) highlights four keys areas to focus the design on in order to cover all the required sections
of a complete system design.
• System Content
• Navigation Structure
• Visual Design
• Technical Design
As, however I am using an evolutionary prototype approach to the system these are merely
suggestions to the design and could be added to depending on progress and responses with the users.
5.1 System Content
Based on my findings from the requirements analysis and the original minimum requirements set in
the introduction there will be two major areas of content. There will be a test to determine the users
learning style and questions to follow this up in a specific learning style.
The material being tested is basic numeracy with addition and subtraction specifically being targeted.
So it makes sense that the test for the best learning style would also be based on this. This also
supports the idea mentioned in the background reading that most of the learning style tests currently
available are not appropriate for young children.
The material must represent at least two different learning styles. I spent a lot of time debating which
two would represent different enough learning styles whilst also being possible to code. I settled on a
logical learning style and a verbal learning style.
The logical learning style is similar to Kolb’s Abstract Reflective style or the Logical Mathematical
learning style from the Multiple Intelligence theory. It favours those who learn from being presented
the facts without any unnecessary distractions. These learners do not need imagery, be it verbal or real,
to demonstrate an idea. They simply need the facts. This will require that the learning styles test
- 20 -
content represents an equal proportion of questions in this style and that there is a selection of
questions afterwards to further teach in this style.
The verbal learning style is similar to Kolb’s Concrete Active or the Verbal/Linguistic learning style
from the Multiple Intelligence theory. It favours those who learn best from real world situations that
they can imagine and solve in this way. They need a scenario and a way to put the problem into this
scenario. From this they can process the problem with greater ease. The facts alone tend to confuse
them as they cannot hold any significance to them without a real world equivalent. This will require
that the learning style test content represents an equal proportion of questions in this style and that
there is a selection of questions afterwards to further teach in this style.
The system will also need to show the results of any test taken. This will keep the users informed of
their progress and help them understand the workings on the system. It also allows them to see their
mistakes and learn from them. This is proven way of learning as it not only gives confidence for every
right answer but also helps them learn their weak points for future exercises.
5.2 Navigational Structure
Even a perfect system needs to allow a user freedom to use it. This comes through good navigation
options. A user must feel like they can not only progress through a system but leave it or revisit pages
as necessary.
This system will incorporate a relatively linear process stream as it is merely a prototype. This means
it will not contain enough content to allow users personal paths through the content.
To achieve this, a good layout is required. This comes best from a hierarchical view of how the user
progresses throughout the system. This is demonstrated below in Figure B.
This diagram shows how the user not only achieves the their learning style (progression down the left
hand branch of the diagram) but also how the next time they use the system they proceed directly to
the learning tasks for their style.
- 21 -
Figure B.
Each page will also have a link at the bottom to allow the user to log out of the system returning them
to the main page. This will stop users accessing other people’s accounts within the system if it is used
on the same machine.
The names for each of the links comply with the tradition that they should be informative but concise
so as to allow the user to understand what they are clicking but also not clutter up their view. (Dix et
al, 2004)
5.3 Visual Design
The majority of users will never see the code or design work that goes into a system, they judge the
system only by the output given to them (Kendall, 2005). This means that the system must show the
output in a way that shows the full potential of the system.
To demonstrate the generic layout of my system I have drawn a template that will be used for the
system. Not all pages will necessarily use this layout as some may have special requirements, but by
using it on the majority of screens it will create a familiar working atmosphere for the users.
I will keep the colours used with the system simple so as not to cause distractions. I will however have
the menu highlighted and the Titles in bold to highlight them to the users attention.
Main Page
Register
Login
Take Learning Style Test Get Learning Style
Get Test Answers
Contacts
Answer Questions
Get Learning Style
Answer Questions
- 22 -
Figure C
5.4 Technical Design
The technical side of the system covers not only how all of the above is presented but also how the
data is stored and manipulated. In this section I shall illustrate my plans for the system.
5.4.1 Website
There was originally debate over the deliverable for the system. There was a possibility for a stand
alone system but after discussions with the intended users it was decided that a web based system
would be preferential. This is because of the portability of the World Wide Web. Teachers suggested
that the ability for children to study at home as well would be a big advantage.
There are a multitude of methods for creating websites nowadays. The main HTML basis still remains
as the most popular standard. This will be used to give the system its shape and structure. However
more will be needed to give it its functionality. To do this I will need to use a scripting language to
handle the forms and exercises.
A scripting language accesses data from a server, in this case a web server, and then returns it to the
webpage. From this I will be able to manipulate users details by connecting to the database.
ME
NU
- 23 -
5.4.2 Database
The database will be a postgres relational database. There will be an accounts table detailing the user’s
details, two tables to deal with the learning style test and results and two tables to deal with the
subsequent questions and results.
Postgres was developed in Berkley in the 1970’s. You can connect to a PostgreSQL sever using a
number of different languages, including C, C++, JDBC, Perl and Python. As such it is a versatile and
can be extended to cover new data types.
The diagram below shows the relationships between the test tables and the accounts table. Each user
will have to take the original learning style test and their results will be stored in the Test Results table
which is compared to the Test table to answer the questions. The same setup will be used with the
Questions in the system.
Figure D
The accounts table will contain a username and password to grant access to the system, two learning
style values to represent the stereotypes being applied and a marker to indicate if a user has completed
the initial learning styles test.
Accounts
Test Results
Test
- 24 -
The test table will contain a series of questions and some multiple choice options for them. This is
only for the original questions, all following ones will not be multiple choice due the “gaming” the
system issues discovered from the background reading. The table will also contain the correct answer
to allow for marking. Each question will also have its own learning style associated with it. This will
mean that when this question is answered the relevant learning style and the correct value in the
accounts table is incremented.
5.5 Summary
As the end result of this project is not an overly complex system, an overly complex programming
language should not be required. As such I have decided to use CGI with embedded HTML. This will
be done using the Python programming language to embed SQL statements and HTML into the CGI
pages.
The HTML will also make use of a CSS file to ensure that the format of the system remains constant
for the reasons stated above.
- 25 -
Chapter 6: System Implementation
I implemented my system using the prototype methodology as detailed in the previous chapter. As
such there were several iterations before the final prototype was completed. Here I have detailed the
steps completed in each individual iteration.
Also, I settled on my technical options. I hosted the website on the School of Computing server using
a postrgres database on their servers also. This was not only the most convenient option open to me as
all of the setup was taken care of in advance for me, but also the safest option. All work is backed up
daily and any technical issues could be quickly dealt with making the system more reliable.
I chose to use Python with CGI embedded in HTML to access the database as I already have
experience programming basic websites with this. This will call SQL statements to the database to
display details.
The first prototype developed is planned to be a design of the system only. It will show the outline and
provide little to no functionally. It will merely demonstrate the navigation and options to be provided
by the system.
The second prototype will incorporate a login system and the learning styles test. It will also mark the
test. This will be the main basis of the system and the questions will be under scrutiny. They will need
to be suitable not only for the level at which they are testing but also for the two learning styles being
used.
After this prototype stages will continue as needed to add to the system.
6.1 First Iteration Prototype
The first iteration was an outline of the system. It contained each of the views that would be presented
to the user as they navigated the system.
The front layer of the website (before you login or register) was setup to contain a short description of
the system and a contacts page so that users may know what the system intends to do and how express
their views on the results. The login page and register page were kept simple so as to make their
purpose clear.
- 26 -
Following the login page the user should be presented with one of two options. If they are new to the
system then they are presented with the learning style test (Screenshot A). After submitting this form
they will be shown the results of their test to keep them informed of their progress (Screenshot B). The
next step is to calculate and inform the user of their learning style according to the test results
(Screenshot C). Any blanks on these screenshots represent data that will be taken from the database.
Screenshot A
Screenshot B
- 27 -
Screenshot C
This skeleton system was shown to as many teachers and teaching assistants as possible, some where
unavailable for comment. They saw the outline as a good idea but wanted to see the next step where
learning material is actually suggested.
One teacher also suggested that users be informed each time there learning style is changed. This they
thought would help the teacher and possibly child understand what was going on. This will be taken
into account for the second iteration prototype.
6.2 Second Iteration Prototype
This is where the functionality of the system was implemented. The database was populated with
enough data to represent the potential of the system. The buttons were given code to call python
functions performing the necessary page or database manipulation.
The Register page was made to take the input from the user for a username and password and store
this in the accounts table. It also initialised data into the Test and Question Results table to set all their
answers to zero; this would be required later when this table was to be updated.
The Login page was made to pass the username to the subsequent pages so that a session was created.
This would ensure that only the data for the user logged in would appear in the system. This is a
method that is very poor security wise but as this is only a prototype system the issue of security is
irrelevant for this area.
- 28 -
The Learning Styles Test page was made to take the questions from the Test table in the database and
show them in a table with radio buttons for each option in the multiple choice test. The function was
also added so that when the button was pressed the users input was sent to Test Results table. This is
shown in Screenshot D.
Screenshot D
The next page displayed the results from the test. This was the user’s results from the previous test
marked against the correct answer in the table. As suggested I added a remark on not only if the
answer was correct but also the affect it had on the users learning style. This is shown in Screenshot E.
- 29 -
Screenshot E
The learning style was then created. In the case of both values, verbal and logical learning style, being
equal a balanced learning style is assigned. This will give a mixture of questions in the follow up
exercise, as demonstrated in Screenshot F.
Screenshot F
For a logical learning style only the first ten questions would be displayed, and in the event of the
users learning style being verbal the last ten questions would be put into the table.
- 30 -
I showed the results of this prototype to as many teachers and assistants as possible again. They liked
the simplicity of the test and agreed it would be suitable for the children to understand. They also
commented on the closeness of the question styles to the curriculum and some agreed that the two
opposite styles represented two possible stereotypes for children they know.
6.3 Third Iteration Prototype
This final iteration took place near the end of the project schedule and consisted mainly of tying up
loose ends and improving the human interaction area of the system.
I added error messages to prevent all questions not being answered. An error now appears if all
questions are not answered and the database is not updated. An error was also setup so that a user has
to enter values into the login screen and register screen. I also made sure that after a test was taken the
user’s test_done value was changed to one after the test is completed so they cannot take it again.
Due to time constraints both on Mr Greenop’s and my schedule, feedback could not be retrieved for
this prototype although all changes had been run by him before implementation began, to assure their
worth.
6.4 Summary
This section assessed the implementation phase of the project. This was a very lengthy stage as it
relied coding which took a while to set up especially with the database and server being hosted by
other people. There were a couple of problems with server downtime but not enough to throw my
project too off schedule.
The responses and evaluation by the Teachers and Teaching Assistants was invaluable to the project
completion as it was their views along with the original research findings that shaped not just the final
prototype, but also the project. The lack of feedback from Mr Greenop was disappointing but
unavoidable.
The completion of the prototype however does not show the success of the project as a whole, merely
its implementation. I will have to evaluate all aspects of the project to assess its success.
- 31 -
Chapter 7: Project Evaluation
The project as a whole will be evaluated not only the responses of the teachers but also by its value.
This can be assessed by comparing the plans for the start of the project with the final outcome.
7.1 Comparisons to Project Aim and Requirements
“To investigate the use of learning styles in teaching and assess the possibility of using these learning
styles in a Computer Aided Learning Scheme.”
The research undertaken in Chapter 2 of this project investigated not only the use of learning styles in
education but also the implementation of this in Computer Aided Learning. It was found that the idea
was around but wide scale implementation was yet to be achieved.
“A user’s style will be based on a user’s performance on set questions.”
This was incorporated into the system by setting a Learning Style Test at the start of the system to
assign the user a learning style.
“The system should also have the scope to adapt a user’s style based on their continuing
performance.”
This option was not implemented but the potential was there for future development. Whereby the
questions set based on the users learning style would also o be used to constantly adapt their learning
style based on the user’s responses.
The three minimum requirements (listed below) where all achieved within the set timeframe. Learning
Styles were investigated ranging from Kolb’s theory to the Multiple Intelligence theory of Meir. Two
styles were then designed for the systems use and material made available in a prototype system. The
users were also assigned one of these learning styles of a “balanced” learning style based on a test
taken upon entering the system.
1. An analysis of various Learning Styles developed for children and their place in Computer
Aided Learning.
2. A framework Computer Aided Learning System to demonstrate the uses of different learning
styles in teaching basic primary school number work (addition, subtraction etc).
3. Extensions to the above assigning users a learning style based on the results of a learning
styles test
- 32 -
The possible additions below where only partially achieved due to time constraints. The automatic
assigning of further tasks was added but the updating of learning styles did not get complete
implementation.
1. Automatic assigning of tasks to suit the users chosen learning style once the test has been
completed
2. Constant updating of users learning style as they continue to use the system
7.2 Teachers Feedback
Feedback throughout the project, from Nick Greenop and the Teachers I had access to, was positive.
They welcomed the idea of such a system, but were of course sceptical of its possible shortcomings. I
made clear to them that this was just a prototype and was by no means a finished system and this
seemed to get their enthusiasm back.
A few teachers did not agree that children could be stereotyped in such a way, although some admitted
that they used such methods in their class to group children together. These teachers did specify that
the groups were too wide and generic and suggested that the system take into account all the child’s
styles, not just the dominant one.
They saw a complete system as something that would definitely be a good addition to their classroom
tools. It would not only be something to aid the child’s learning but also help them quickly assess a
child’s abilities and shortcomings, highlighting the best approach to be taken with them in future.
They were however keen to stress that they could not see it being used as a solitary tool and that it
could not be totally relied on to teach a child.
7.3 Potential Future Additions
The future potential of this project is the development into a full system. This would require a lot more
research and coding to improve the standard. The design of the system would require more scrutiny to
make it not just suitable for children but also appealing. The system would need to cater to a wider
range of learning styles and incorporate elements of imagery, auditory and possibly tactile options of
moving items around on screen.
7.4 Evaluation of Project Stages
Each stage was completed to a satisfactory level and the results found and used from each proved very
useful in the completion of this project.
- 33 -
The research into all the areas proved priceless in planning the later stages as it helped to understand
not only what needed to be accomplished but also what could be accomplished. The methodology and
requirements analysis helped to finalise the goals of the project and put them into an order of events
that could be approached knowing the expected outcome. The system design save d a lot of time later
on as it meant that when it came to creating the prototype the style and technical specifications were
clear and quickly created. By using an evolutionary prototyping method for implementation I was able
to constantly build upon my system based on user feedback.
7.5 Conclusion
The use of computers in education is growing daily. With more and more children in our schools and
fewer teachers this is understandable. Computers coupled with good software can reduce work loads
and help our jobs; this is no different with teachers. The potential for a system of this nature, to help a
teacher not only teach but understand their students more, is obvious.
I feel that the project has been a success based on its completion of minimum requirements and its
compliance to the project aim. All minimum requirements were met and within the timeframe set.
- 34 -
References
1. Arnheim. R, (2004), Visual Thinking, University of California Press
2. Askew, M. Brown, M., Rhodes, V., Johnson, D., Wilian, D. (1997) Effective Teachers of
Numeracy. Report of a study carried out for the Teacher Training agency 1995-1996 by the
school of Education, King’s College London. London: King’s College
3. Avison, D and Fitzgerald. G, (1988) Information Systems Development, Oxford: Blackwell
Scientific.
4. Beale C, (2006), Fitting Software to Students, www.isi.edu/news/print.php?story=142
[25/01/07]
5. BECTA, (2006), Advice and Guidance for E-Learning Content Providers,
http://publications.becta.org.uk/, [07/03/07]
6. BECTA, (2006), Supporting Learning and Teaching Primary Schools,
http://publications.becta.org.uk/, [07/03/07]
7. Bourne. JR and Moore. JC, (2004), Elements of Quality Online Education: Into the
Mainstream, Sloan-C
8. Brusilovsky P (editor), (1996), Multimedia, Hypermedia, and Virtual Reality: Models,
Systems, and Applications, Springer
9. Crinnion J, (1991), Evolutionary Systems Development. Springer
10. Dix, A., Finlay, J., Abowd, G. Beale, R. (2004) Human Computer Interaction 3rd ed. Upper
Saddle River
11. Douglas. K and Douglas. S, (2003), PostgreSQL: the comprehensive guide to building,
programming, and administering PostgreSQL databases, Sams Publishing
12. Cabinet Office, (2007), Minister and experts announce major progress in first year of Transformational
Government strategy, http://www.cabinetoffice.gov.uk/newsroom/news_releases/2007/070110_ciostrategy.asp
- 35 -
[18/02/07]
13. Gardner. H, (1993), Multiple Intelligences: Theory in practice, Basic Books
14. Jameson. A, (2001), User-Adaptive and Other Smart Adaptive Systems: Possible Synergies,
http://www.eunite.org/eunite/events/eunite2001/look_back/13261_P_Jameson.pdf [22/03/07]
15. Kendall. K & Kendall. J. (2005) Systems analysis and design: Prentice Hall.
16. Kimble (editor) (1967) Foundations of conditioning and learning New York : Appleton-
Century-Crofts.
17. Kolb D, (1984), Experiential Learning: Experience As The Source Of Learning And
Development
18. Kotonya. G and Sommerville. I, (2000), Requirements Engineering: Processes and
Techniques, John Wiley & Sons
19. Leask. M and Meadows. J, (2004), Teaching and Learning with ICT in Primary Schools
Routledge Falmer
20. Meir. P and Warren. A, (2002), Integrating Technology in Learning and Teaching, Routledge
21. Ofsted, (2004), Inspection Report for Easterside Primary School Unique Reference 111622
http://www.ofsted.gov.uk/reports/pdf/?inspectionNumber=256026&providerCategoryID=16&
fileName=%5C%5Cschool%5C%5C111%5C%5Cs10_111622_20040610.pdf. [03/03/07]
22. O’Shea. T and Self. J, (1986), Learning and Teaching with Computers - Artificial Intelligence
in Education, Harvester Press Ltd
23. Overmyer, S.P, (1991), Revolutionary vs. evolutionary rapid prototyping: balancing software
productivity and HCI design concerns. In: Proceedings of the 4th International Conference on
Human-Computer Interaction
24. Rees, M White, A White B (2001), Designing Web Interfaces, Prentice Hall
- 36 -
25. Sametinger J, (1997), Software Engineering with Reusable Components, Springer
26. Weber G, (1996), User Modeling and Adaptive Navigation Support in WWW-Based Tutoring
Systems,
- 37 -
Appendix A: Personal Experience
In completion of this project I am pleased with not only the outcome but also my experiences gained. I
enjoyed learning about new subjects that tie in with computing and its real world use. I have learnt not
only about Computing in Primary Schools but also Learning Styles and their use in assessing an
individuals potential.
The magnitude of the task seemed daunting upon undertaking the project and in the latter stages. I
have had experience on large projects but only in groups where the work is shared. I feel that I have
learnt a lot from working on my own as I tested my own abilities and developed many skills. I now
fully appreciate the workload involved with a project of this size.
In hindsight I feel that I could have been better organised for the project and as a result achieved more
by the final deadline. I also feel that my research time could have been spent more productively. I also
wish that I had more time to further develop the project and see it in its later stages.
I learnt a lot about time management and the importance of keeping on schedule. Fitting my normal
modules and this one into my time was a challenge and one that I feel I am now better prepared for in
the future. I also learnt a lot about forming and compiling a report of this nature and hope to have the
chance to do more in future.
Overall I have enjoyed the experience and watching something that was not a group project develop
over time was extremely satisfying. The biggest reward was the feedback from the teachers and their
support.
- 41 -
Appendix D: Subjects in Curriculum
Sets and Sorting
• Attribute Cards
• Guess What…..
• Snap
• Ven Diagrams
• Relations
Counting
• Rhymes/Memory
• Tallys
• Grouping
• Patterns
• Number Lines/Squares
• Number Bonds
• Dice Games
• Guess the Rule/Number in Pocket
• FizzBuzz
Amounts
• Area/Volume
• Money
• Time
- 42 -
Appendix E: Current Software
MathsWhiz 1
• Timed Element
• 120+ Exercises
• Addition/Subtraction (0-1000+)
• Multiplication/Division (2x – 1000’s)
• Decimals/Fractions (including comparison)
• Negatives, Number Line (thermometer)
NumberShark 3
• Attention Span orientated
• 41 games
• Student management system
• Record keeping
• Allows games to be differentiated for individual systems
Government Creative Remote Interactive Teaching Programs:
• Free
• Interactive White Board Compatible
• Not Game Based
• Education (not enjoyment) focus
RM
• Friendlier
• Teachers can create resources
GOAL Software
• SAT’s based
• Analysis of progress
• Subscription based
• Targets based
- 43 -
Appendix F: Example Questions
Year 1 Unit 4 (Autumn term) Resource sheet 4.2 1. There are 10 people on a bus. At the next stop 2 more people get on. How many people are on
the bus now?
2. There are 11 people on the bus. 1 gets off at the next stop. How many are left on the bus?
3. There are 6 children waiting to go down the slide. 2 go down the slide together. How many are
still waiting?
4. A pencil case was £3. In the sale it is £1 less. How much is it now?
5. 2 children are playing on the roundabout. 5 more come to join them. How many are there
altogether?
6. There are 5 children sitting at one table, and 5 children at another. How many children are
there altogether?
7. You roll two dice and get 3 on each dice. What’s the total?
8. You are on number 10 on a number track. You roll the dice and get 2. You move 2 steps.
Which number will you land on?
9. There are 2 pegs at one end of the coat hanger, and 8 at the other. How many are there
altogether?
10. There are 20 birds sitting on a roof. 1 flies away. How many are left?
Year 1 Unit 4 (Autumn term) Activity sheet 4.1
1. 7 - 2 =
2. 7 - 3 =
3. 10 - 1 =
10 - 2 =
10 - 3 =
4. 9 - 1 =
9 - 2 =
9 - 3 =
5. 6 - 1 =
6 - 2 =
6 - 3 =
Taken from
http://www.standards.dfes.gov.uk/primary/teachingresources/mathematics/nns_unit_plans/year1/Y1T1
Unit4Addandsubstract/nns_unitplan050803y1t1unit4.pdf
- 44 -
Appendix G: DB Schema
Table Name Fields
accounts username varchar (12) primary key,
userpword varchar (12),
ls_1 int,
ls_2 int,
test_done int,
date_time timestamp
test test_id serial primary key,
test_question varchar(500),
test_answer1 int,
test_answer2 int,
test_answer3 int,
test_answer4 int,
test_correct int,
test_ls varchar (10)
testresults username varchar (12),
test_id serial,
test_answer int
questions question_id serial primary key,
question_wording varchar (500),
question_ls varchar(10),
question_answer int
questionresults username varchar (12),
question_id serial,
question_answer int