Dissertation (Final Version)

The Final Year Engineering Project (PJE40)
Daren James Stratton Page 1
TABLE OF CONTENTS
Chapter 1 – The Introduction............................................................................................................................................3
Resources for the Project...............................................................................................................................................3
The Rationale of the Project .........................................................................................................................................3
The Maths Program: Aims and Objectives ..............................................................................................................3
Chapter 2 – The Literature Review..................................................................................................................................5
The Accessibility Requirements: W3C/WAI.............................................................................................................5
PowerMapper: Online Accessibility Checker ..........................................................................................................5
The PowerMapper Analysis: KS2 Maths Websites................................................................................................6
Website 1: BBC Bitesize (KS2 Maths).....................................................................................................................6
Website 2: IXL Maths UK ...........................................................................................................................................7
Website 3: M@thsZone..............................................................................................................................................8
To Conclude the Research...........................................................................................................................................10
Chapter 3 – Methodologies..............................................................................................................................................11
The Four Design Methodologies................................................................................................................................11
The Sprial Methodology ...........................................................................................................................................11
The Waterfall Methodology ...................................................................................................................................12
The Analyst’s Approach...........................................................................................................................................13
Object-Oriented Design...........................................................................................................................................14
The Two Project Management Methodologies ...................................................................................................15
The Prince2 Methodology ......................................................................................................................................15
The Dynamic System Development Method...................................................................................................16
The Final Choice of Methodology ............................................................................................................................17
Chapter 4 – The Requirements.......................................................................................................................................18
The User Requirements ................................................................................................................................................18
The Functional Requirements ....................................................................................................................................18
The Technical Requirements.......................................................................................................................................19
The HCI Requirements.................................................................................................................................................20
Accessibility Requirements....................................................................................................................................20
Usability Requirements...........................................................................................................................................20
Chapter 5 – The Design.....................................................................................................................................................21
The Alpha Versions.........................................................................................................................................................21
The Beta Versions .......................................................................................................................................................... 22
The Final Versions.......................................................................................................................................................... 24
The Summary...................................................................................................................................................................25

Chapter 6 – The Prototyping..........................................................................................................................................27
The Practicals...................................................................................................................................................................27
The Quizzes ......................................................................................................................................................................27
The Games........................................................................................................................................................................28
The Deprecated Features............................................................................................................................................29
Chapter 7 – The Implementing .....................................................................................................................................30
The Implementation Method....................................................................................................................................30
Problems Encountered.................................................................................................................................................30
The Solutions....................................................................................................................................................................31
Chapter 8 – The Testing Sessions.................................................................................................................................32
The First Testing Session: December 2012............................................................................................................32
The Second Testing Session: February 2013 ........................................................................................................32
The Risk Analysis............................................................................................................................................................ 34
Chapter 9 – Evaluating Against Requirements........................................................................................................35
The Maths Program: Usability...................................................................................................................................35
The Maths Program: Accessibility............................................................................................................................ 35
The Maths Program: Does this meet the Requirements?...............................................................................35
Chapter 10 – The Conclusion..........................................................................................................................................36
Gantt Chart: Scheduling ..............................................................................................................................................36
The Waterfall Methodology: Did it Work? ...........................................................................................................36
The Maths Program: Conclusion.............................................................................................................................. 37
The Maths Program: Future Directions..................................................................................................................37
References.............................................................................................................................................................................39
Table of Figures ...................................................................................................................................................................41
Appendices ......................................................................................................................Error! Bookmark not defined.

CHAPTER 1 – THE INTRODUCTION
This project explores about the different needs of The Maths Program, explains about the resources
required, and looks at its rationale. This also looks at the aims and objectives of developing The
Maths Program. This explores into the different issues when designing for the typical human user,
and looks into Human Computer Interaction design. The research analyses three different websites
available to children of the Second Key Stage, and PowerMapper checks the first ten pages of each
website. This is to track any errors within the page, and refers from Schneiderman and the W3C/WAI.
This also explores into detail about different methodologies, explaining more in depth about the
choice of methodology that The Maths Program is following.
This project looks at the different requirements of The Maths Program, and analyses the capable
limits of the children of the Second Key Stage. The Second Key Stage lasts from when a child starts
Year 3, until when they finish Year 6 (IXL UK: Maths, 2013). This also covers the different designs of
The Maths Program, and explains about the prototyping stages, implementing, testing, and
evaluation.
RESOURCES FOR THE PROJECT
In order for this project to be successful, it shall require an Operating System that is at least Microsoft
Windows XP. Additionally, other requirements include Microsoft Visual Studio 2012, the Microsoft
.NET Framework version 4.5, and Microsoft Office 2013 (however, Microsoft Office 2010 version is
also acceptable, because Microsoft Office 2013 version was a consumer preview at that time).
In order for The Maths Program to be fully accessible and usable, the colour scheme must have the
appropriate contrast. For example, if you have a dark background colour, you must have a lighter
colour text. The default setting of the background colour is normally that of a typical dialogue box,
and the setting of the text colour is black by default. However, since you may not be able to tell
which buttons are enabled and which ones are not, if you have a blue background (or another dark
colour), change the colour of the text to white. This makes it easier to determine the state of the
buttons, whether enabled or not.
THE RATIONALE OF THE PROJECT
The rationale of this project is, “How do children of the Second Key Stage interact with everyday
Maths?” The Maths Program attempts to provide an interactive approach to help children solve
everyday problems concerning Maths. This project also attempts to analyse the Mathematical
knowledge of a Key Stage Two child, applies it to the main interface, and offers different games that
will help broaden and enhance their experience and knowledge.
THE MATHS PROGRAM: AIMS AND OBJECTIVES
This section explores the different aims and objectives; these ensure that The Maths Program runs
smoothly. This shall also run in a complete parallel to the Project Initiation Document.
The main aim of this project, is to create a Maths Program, which allows children of the Second Key
Stage (“this key stage runs from Years 3 to 6, and the age range of between 7 and 11” (IXL UK:
Maths, 2013)) improve on the Maths skills developed in their previous Key Stage. Additionally, The
Maths Program must have maximum interaction within the intended audience (Second Key Stage
children), and it must allow room for errors.

In order to ensure that the objectives meet the aim of The Maths Program, there are some sub tasks
within these objectives.
1. Therefore, since The Maths Program aims at children of Key Stage Two, The Maths Program
needs to be fun and easy to use.
2. Additionally, to ensure the accessible use of The Maths Program, this must have appropriate
colour schemes. This ensures that The Maths Program is accessible enough for the intended
audience.
The Maths Program will also include features that have the greatest relevance to Second Key Stage
Maths.
3. Therefore, to ensure maximum interaction and that a child has multiple tries during a round;
they will have 15 lives in the quizzes, and unlimited lives during a practical.
4. The child should also have the opportunity to score points per quiz. To ensure this happens;
they will score 20 points (for each life intact) for every correct answer given. This means that
they can score a maximum of 3,000 points
If a child is stuck, they must be able to seek help by the best possible media. Since The Maths
Program aims at Key Stage Two children, the best way to help them is through animation.
5. Therefore, in The Maths Program, there will be a specialist Tutorial Centre, which covers the
entire range of the features The Maths Program offers.
6. Additionally, The Maths Program will team with Go Animate to create the videos, and the
theme set to Comedy World. These videos will have a timeline setting of 2088.
7. The users must be able to replay the videos, if they need them repeated.
8. The Maths Program must present users with a working calculator function in all of the
practicals and quizzes, and they should be able to use these with ease.

CHAPTER 2 – THE LITERATURE REVIEW
This literature review explores through the different games available to children of the second key
stage. This also includes the different aspects of Mathematics that children learn throughout this key
stage. This also explains about the requirements of accessibility, and includes the requirements
requested by an accessibility organisation called W3C and WAI. This also explores through a range of
websites available for children to use, and looks at how they enhance the knowledge obtained during
the child’s previous key stage. There will also be a user analysis based upon how accessible each
website is. These focus on the requirements set out by W3C and WAI. Figure 2:1 gives a more
generalised breakdown of The Second Key Stage within all British schools.
Year Ages
3 7 – 8
4 8 – 9
5 9 – 10
6 10 – 11
PJE40 2:1: T HIS IS T HE BREAKDOWN OF T HE SECOND KEY ST AGE IN ALL BRIT ISH SCHOOLS (IXL
UK: MAT HS, 2013)
THE ACCESSIBILITY REQUIREMENTS: W3C/WAI
This section looks into, and explores the different accessibility requirements; these are the
accessibility requirements set by The W3C/WAI. Additionally, upon looking at these requirements, this
looks at the features of three different web sites, and determines whether they have met the
requirements set by The W3C/WAI.
The main web site of The W3C/WAI organisation, lists out the requirements expected to work in
“Web Content Accessibility Guidelines (WCAG)” (Vanderheiden, Slatin, & Chisholm, 2006). The
W3C/WAI emphasise that, in order to make a website that is fully compatible, you have got to,
“ensure that the requirements are clear, and that they can be applied across technologies”
(Vanderheiden, Slatin, & Chisholm, 2006). Additionally, the W3C/WAI mention the other
requirements, and they say that you must also, “design the deliverables with ease of use in mind, you
need to ensure that you’re writing to a more diverse audience” (Vanderheiden, Slatin, & Chisholm,
2006). This also mentions that you are required to, “ensure that the new revision is “backwards and
forwards compatible” and that you must clearly identify who would benefit from the accessible
content” (Vanderheiden, Slatin, & Chisholm, 2006).
POWERMAPPER: ONLINE ACCESSIBILITY CHECKER
There are several different accessibility tools available on the Internet, and the checker used for the
three websites being analysed, goes by the name of PowerMapper. Power-Mapper is an online web
accessibility checker, which analyses a wide range of webpages, checking for any issues or errors.
The analysis of PowerMapper is said to “include 112 checkpoints covering WCAG 2.0, 86 checkpoints
covering WCAG 1.0, and 53 checkpoints covering the 15 guidelines concerning Section 508”
(PowerMapper, 1996). There is a mini online checker within PowerMapper called SortSite. This checks
webpages for any issues, which may prevent a disabled person from using that particular website
(PowerMapper, 1996). This prioritises different features by three different levels; these levels are A,
AA and AAA (PowerMapper, 1996).
If the issue or error has the level “AAA”, it would mean that person would find that particular page
somewhat difficult to navigate (PowerMapper, 1996). If the issue or error has the level “AA”, it would
mean that person would find that particular page more difficult to navigate (PowerMapper, 1996). If
the error or issue has the level “A”, it would mean that person would find that particular page

impossible to navigate (PowerMapper, 1996). Sort-Site checks through all websites against W3C,
WCAG 1.0 and 2.0 requirements, and it checks for compliance with Section 508 of The Rehabilitation
Act (PowerMapper, 1996). The evaluated trial version will check the first 10 pages of the website, and
it is purchasable on their website from £99.
THE POWERMAPPER ANALYSIS: KS2 MATHS WEBSITES
This section explores through the wide range of websites, which are available to children of The
Second Key Stage. These websites include different Maths activities, in which the children learn at
Primary School. There are three different websites covered in this literature review; each of them
shall have a run-down analysis based on their levels of accessibility. The run-down analysis includes a
performance check for accessibility issues within the different websites. The name of the program
performing these checks is SortSite.
WEBSITE 1: BBC BITESIZE (KS2 MATHS)
This website provides the child with different Maths activities, which are organised into number,
shapes and measures, and data handling. You get the opportunities to collect bio-rods from Mission
2110, collect mystery prunes from Dick and Dom, and to save zooks in Bamzooki (BBC, 2013). Figure
2:2 shows you the layout of a typical page from BBC Bitesize.
PJE40 2:2: T HIS IS T HE MAIN NUMBER PAGE OF BBC BIT ESIZE, W HICH COV ERS T HE BASIC
ASPECTS OF MATHS, INCLUDING FRACT IONS, PERCENT AGES, AND PLACE V ALUES (BBC, 2013)
The number section of BBC Bitesize focuses on numeracy aspects; these include Addition and
Subtraction, Decimals, Fractions, Factors, Money and Percentages. This also includes different types
of number organising games, which will allow the child to work with Place Values and Patterns (BBC,
2013). This website also offers opportunities to read about the content (if reading is your learning
style), and to do the quiz (if you are hands on with the learning style of kinaesthetic) (BBC, 2013).
Additionally, when you submit your answers, it will then tell which you which ones you answered
correctly, and which ones you got wrong (BBC, 2013).
The BBC Bitesize website went under the Power-Mapper analysis check for any errors or issues with
the website, and the results show that 45% of all Maths on Bitesize have errors or issues (SortSite:
BBC Bitesize, 2013). Additionally, these results conclude that, “the majority of all problems found
within this series of websites, are Priority A. Therefore, this makes browsing this website impossible
for someone who either deaf, blind, or maybe even both” (SortSite: BBC Bitesize, 2013). Figure 2:3
shows you the analysis results carried out on BBC Bitesize, and explains about what percentage in
errors, that this website contains.

PJE40 2:3: T HE RESULTS SHOW T HAT 45% OF T HE ENTIRE COLLECTION OF NUMBER PAGES FROM
BBC BIT ESIZE HAS ISSUES OR ERRORS. RESULTS ALSO SHOW T HAT T HE MAJORIT Y OF ERRORS
CONCERN PRIORIT Y "A" (SORT SIT E: BBC BIT ESIZE, 2013)
Additionally, the links provided in the website, do not give out alternate links, which increases the
difficulty for a blind child if they want to navigate through this website (SortSite: BBC Bitesize, 2013).
This is the case also, because smart readers (i.e. ClaroRead and IVONA Reader) do not even say
anything back, when you move your mouse over a link (SortSite: BBC Bitesize, 2013). SortSite
encountered other errors within the website of BBC Bitesize, of which include, “lack of FIELDSET tags,
and if there were any, they were not appropriately labelled with the correct LEGEND tags” (SortSite:
BBC Bitesize, 2013).
WEBSITE 2: IXL MATHS UK
This website provides links to different activities, in which schoolchildren participate during their
lessons. This website organises all of the links into their relevant categories, and this makes it easier
for the child to select which activity they would like to participate in (IXL UK: Maths, 2013). When a
child clicks on one of these links within IXL Maths, this website presents them with an exercise page.
This offers them the opportunity to enhance their skills (IXL UK: Maths, 2013). Based upon the
performance of the child, this website awards them different marks. This website awards points per
question up to a maximum of 100; these figures depend on the time taken per question (IXL UK:
Maths, 2013). You can also choose how this website organises the skills; these are by either topic or
year (IXL UK: Maths, 2013). Figure 2:4 gives you the general idea of what IXL Maths looks like in The
United Kingdom, as this website caters for seven different English-speaking countries (IXL UK: Maths,
2013).

PJE40 2:4: IF Y OU ARE A ST UDENT IN Y EAR 4, T HIS LIST S T HE SKILLS T HAT Y OU W ILL LEARN.
MANY OF T HESE SKILLS ARE A STEP-UP FROM W HAT Y OU W OULD HAV E LEARNT IN Y EAR 3 (IXL
UK: Y EAR 4 MAT HS, 20 13).
The IXL website went under the SortSite analysis spotlight, and the results show that 63% of IXL’s
pages have errors or issues (SortSite: IXL Maths UK, 2013). Of the ten pages, tested and analysed,
results show that, “this website has not fully met the requirements of “The Priority A” band, as the
webpages lack ALT tags” (SortSite: IXL Maths UK, 2013). Other “Priority A” issues include “lack of
TITLE attributes, LABEL elements, duplicate ID’s and no opportunities to download Acrobat Reader,
whilst there are some PDF pages” (SortSite: IXL Maths UK, 2013). Additionally, this result shows
“compatibility issues with older Internet platforms (i.e. Internet Explorer 5). Additionally, these results
show that there are six usability issues along with seven accessibility issues” (SortSite: IXL Maths UK,
2013). Figure 2:5 gives you a more generalised view of the amount of errors found within the pages
of IXL Maths UK.
PJE40 2:5: T HIS IS T HE ANALYSIS RESULT FOR T HE IXL MAT HS W EBSITE. T HE 63% PART IS NOW
COLOURED IN RED, AS T HIS INDICATES T HE SEVERITY OF T HE ERRORS DET ECT ED W IT HIN T HIS
W EBSIT E (SORT SIT E: IXL MAT HS UK, 2013)
WEBSITE 3: M@THSZONE
This website offers links to different Maths activities, with some of the links taking you to pages on
different websites (M@thsZone UK, 2013). This website consists of links to different activities, in
which the child participates in (M@thsZone UK, 2013). This helps them to enhance their skills and
knowledge, and apply these to everyday Maths (M@thsZone UK, 2013). However, some practicals
may have high-end performances that require extra plug-ins so that they function properly
(M@thsZone UK, 2013). Figure 2:6 gives a more general view of what M@thsZone looks like, and
what the child should expect by means of activities (M@thsZone UK, 2013).

PJE40 2:6: M@T HSZONE GIV ES LINKS T O ACT IV IT IES ON IT S HOME PAGE. W HEN T HE CHILD
CLICKS ON ONE OF T HE LINKS, T HEY INST ANTLY T AKE PART IN T HAT ACTIVITY (M@THSZONE UK,
2013)
M@thsZone went under the SortSite spotlight, and these checks mainly focused on accessibility and
usability. These results show that 72% of pages within M@thsZone contained errors or issues
(SortSite: M@thsZone, 2013). Like the other two websites, this analysis points out that, “the main
concern of this website, is that the content lacks ALT tags, therefore Smart Readers cannot pick up
the content, unless the user highlights the text” (SortSite: M@thsZone, 2013). Additionally, SortSite
points out that, “because 50% of the pages have accessibility issues, and 70% of the pages have
usability issues; disabled users would find accessing M@thsZone virtually impossible, because of the
issues concerning accessibility and usability” (SortSite: M@thsZone, 2013). Figure 2:7 gives you a
more generalised view of the percentage of errors or issues found in the M@thsZone website.
PJE40 2:7: T HIS IS T HE ANALYSIS RESULT OF T HE M@THSZONE W EBSITE. T HESE RESULT S SHOW
T HAT OVER 50% OF T HE PAGES FROM T HIS W EBSITE CONTAIN ERRORS A ND ISSUES. T HEREFORE,
LIKE T HE RESULT ANALY SIS OF IXL MAT HS, T HE NUMBER IS COLOURED RED. (SORT SIT E:
M@T HSZONE, 2013).

TO CONCLUDE THE RESEARCH
As a summary, the three websites covered in this literature review, are a recommendation in Maths
tutoring, because they can help to entertain the children whilst they are learning. These websites
mentioned focus on children of Key Stage 2, although M@thsZone additionally provides games for
children of Key Stage 1. However, based upon the research conducted, this concludes that each of
the websites mentioned in this literature review, has at least three pages with accessibility and
usability issues. SortSite checks each website for issues such as broken links, accessibility and
usability issues, browser issues and so much more. Although this figure still stands at over 40%, The
BBC Bitesize website had the fewest problems (SortSite: BBC Bitesize, 2013). Additionally, results
show that IXL Maths and M@thsZone were almost identical with the amount of errors and issues
detected on their pages. However, the M@thsZone website had 9% more problems than IXL Maths.
Figure 2:8 gives the final analysis of the websites analysed, the amount of problems (in percentages)
each website had, and the priority band(s) to which these problems link.
Name of Website Problems
(%)
Priority Bands
(Issues)
BBC Bitesize 45 Only A
IXL Maths 63 A, AA and AAA
M@thsZone 72 A, AA and AAA
PJE40 2:8: T HIS IS T HE FINAL SUMMARY OF T HE PROBLEMS EACH W EBSIT E HAD, AND W HICH
PRIORIT Y BAND(S) T HE PROBLEMS LINK T O (POW ERMAPPER, 1996)
The main issue that appears across all three websites and the results of each analysis points out that,
“all three websites analysed, lack ALT tags in all of their pages. This is clearly important, because this
is one of the requirements of the “Priority A” band” (PowerMapper, 1996).

CHAPTER 3 – METHODOLOGIES
This chapter explains about six different methodologies available to different organisations. Of the six
methodologies mentioned, four of them specialise in design, and two of them specialise in project
management. The analysis of each methodology includes the structures, advantages, and
disadvantages. This also explains in detail, about the methodology in which The Maths Program is
following.
THE FOUR DESIGN METHODOLOGIES
This section analyses the structure, advantages, and disadvantages of four design methodologies;
these include The Spiral Methodology, The Waterfall Methodology, The Analyst’s Approach, and
Object-Oriented Design. The analysis focuses on the comparison of the advantages and
disadvantages, and shall present the contrasts in a table.
THE SPRIAL METHODOLOGY
The Spiral Methodology structures itself, in the way that allows the iteration of each prototype within
each of the cycles. This risk-oriented software development methodology specialises in the
incrementing of the iteration, which iterates the cycle from within a package (The Software
Development Team, 1988). Figure 3:1 gives a general picture of what The Spiral Methodology is, and
explains about its specialities.
PJE40 3:1: T HE SPIRAL MET HODO LOGY APPLIES T O ANY PROJECT W IT H REQUIREMENT S T OO
DIFFICULT FOR ANY OT HER MODEL (T HE SOFT W ARE DEV ELO PMENT T EAM, 1988).
Boehm developed The Spiral Methodology in 1988, and many projects still use this lifecycle (The
Software Development Team, 1988). This lifecycle best suits a project, whether it has requirements
at a high difficulty level, or if it involves new technology (The Software Development Team, 1988).
The Spiral Methodology allows the developer to “create a highly customised product by using this
methodology” (I Answer 4 U: Spiral, 2011). This helps guide the developer through the design stages
of the prototype, helps test the program for bugs, and debug them where appropriate (I Answer 4 U:
Spiral, 2011). This is also more fluid in the way the programming completed (I Answer 4 U: Spiral,
2011). Figure 3:2 looks at the main advantage, and compares it with the main disadvantage of using
The Spiral Methodology.
Main Advantage Main Disadvantage
“You can develop a highly customised product
using this model” (I Answer 4 U: Spiral, 2011).
“This model is too advanced for some projects,
especially those considered a low risk project” (I
Answer 4 U: Spiral, 2011).

PJE40 3:2: T HE GENERAL ANALY SIS OF T HE SPIRAL MET HODOLOGY COMPARES ONE MAIN
ADV ANT AGE W IT H ONE MAIN DISADV ANT AGE (I ANSW ER 4 U: SPIRA L, 2011).
However, the main disadvantage of The Spiral Methodology focuses on the level, because the
analysts consider it “too advanced for any project that is considered to be too low of a risk” (I Answer
4 U: Spiral, 2011). Additionally, the structure might not be appropriate enough for the developer, in
case they wish to iterate a loop (I Answer 4 U: Spiral, 2011). The Software Development Team
website also points out that, “The success of any project which uses The Spiral Methodology, very
much depends on the phase of risk analysis” (The Software Development Team, 1988).
THE WATERFALL METHODOLOGY
The structure of The Waterfall Methodology breaks down into five main sections, as explained by
“Learn Access with the Smart Method” (Learn Access, 2006). Additionally, Learn Access points out,
“many organisations that use The Waterfall Methodology, base their software products on
requirements, design, implementation, verification and maintenance” (Learn Access, 2006). Figure
3:3 gives a more general view of what to expect from a project following The Waterfall Methodology.
PJE40 3:3: ALTHOUGH W INSTON ROYCE W ROTE T HE W ATERFALL METHODOLOGY IN 1970, A W IDE
RANGE OF ORGANISATIO NS STILL USE T HIS MO DEL FOR V ARIOUS SOFT W ARE PROJECT S (LEARN
ACCESS, 2006).
The Waterfall Methodology best suits project, which focus on commercialism. Examples include
building websites and portals for Electronic Commerce (eCommerce), developing software based on
databases, and building software for different network protocols (I Answer 4 U: Waterfall, 2012).
This methodology best suits for different types of “low-risk” project; some examples include
educational programs, simple-to-use diaries, calendars, schedules, and other small software projects
(I Answer 4 U: Waterfall, 2012). Other benefits include the opportunity for the developer to add in
extra features. In the case of The Maths Program, this takes form of a staircase. This allows the
developer to iterate a loop, and this helps with the continual testing of features, especially when this
tests the features one at a time.
The Waterfall Methodology allows the developer
to iterate a loop, which ensures the ability of
working with multiple features at any one time (I
Answer 4 U: Waterfall, 2012)
The Waterfall Methodology may be considered
too basic for projects considered a high risk
project (I Answer 4 U: Waterfall, 2012)
PJE40 3:4: T HE GENERAL ANALYSIS OF T HE W AT ERFALL MET HODOLOGY COMPARES ONE MAIN
ADV ANT AGE W IT H ONE MAIN DISADV ANT AGE (I ANSW ER 4 U: W AT ERFALL, 2012)
However, this methodology is considered “too basic”, when project have higher risks imposed. In
these cases, The Spiral Methodology is the more appropriate methodology (I Answer 4 U: Waterfall,
2012). Additionally, developers may find it difficult to obtain the requirements as explicitly requested
by the customer, and this includes the impossibility of freezing the specifications during the

requirements stage (I Answer 4 U: Waterfall, 2012). Moreover, although The Waterfall Methodology
allows developers to back-phase during the development, it becomes very costly if you go back too
many phases at any one time (I Answer 4 U: Waterfall, 2012).
THE ANALYST’S APPROACH
The Analyst’s Approach looks at different tasks undertaken by the analysts. This involves looking at
the different tasks, and the analysis of their performances. Satzinger points this out in a peculiar way,
and he mentions about the level of analysis that goes on within this approach (Satzinger, Jackson, &
Burd, 2005). However, he points this out through the means of collecting and analysing information
on the customers, and the financial situations within an organisation (Satzinger, Jackson, & Burd,
2005). Figure 3:5 gives you a general idea of how The Analyst’s Approach works, and how this
analyses the requirements and solutions.
Requirements Solutions
1. Research and Understand the Problem
2. Verify that the benefits of solving the
problem outweigh the cost
3. Define the requirements for solving the
problem
4. Develop a set of possible solutions
5. Decide which solution is best, and make
a recommendation
6. Define the details of the chosen solution
7. Implement the solution
8. Monitor to make sure that you obtain the
desired results
PJE40 3:5: T HE ANALYST'S APPROACH ORGANISES T HE T ASKS W IT HIN T HE APPROACH, AND BY
T HE ORDER OF HOW INFORMAT ION IS ANALY SED (SAT ZINGER, JACKSON, & BURD, 2005)
The Analyst’s Approach allows analysts to carefully, and critically analyse the tasks required for the
project to work successfully (Satzinger, Jackson, & Burd, 2005). Satzinger mentions that, “System
analysis and design is, first and foremost, a practical field grounded in both time-tested and rapidly
evolving knowledge and techniques” (Satzinger, Jackson, & Burd, 2005).

“The analyst can list tasks that need to be
analysed”
This may include tasks, specialised only for the
analyst, therefore more difficult for the typical
developer, to initialise certain tasks from this
approach
PJE40 3:6: T HE GENERAL ANALY SIS OF T HE ANALY ST 'S APPROACH COMPARES ONE MAIN
ADV ANT AGE W IT H ONE MAIN DISADV ANT AGE (SAT ZINGER, JACKSON, & BURD, 2005).
However, since this approach assumes analytical methods, it may include tasks that are specialised
only for the analyst. Therefore, this makes it more difficult for a typical developer to initialise some
tasks from this approach, because the specialist tasks will be unavailable to them. Additionally, this
approach may not be relevant to the task in hand, as written in Satzinger’s book, this looks in
collecting and analysing information on the finances, the organisation, and the behaviour of the
customers (Satzinger, Jackson, & Burd, 2005).
OBJECT-ORIENTED DESIGN
A presentation on SlideShare looks at the comparisons between Structured Analysis and Design and
Object Orient Analysis and Design, and highlights the key points of the two ways of analysis and
design (Saad, 2010). However, this section focuses on the key points of Object-Oriented Analysis and
Design. Like The Spiral Methodology, Object-Oriented Design best suits projects with more of a high-
risk. However, unlike The Spiral Methodology, this also suits projects where requirements constantly
change (Saad, 2010). In Object-Oriented Design, projects consist of object classes, and these have
inheritance from other super-classes (Saad, 2010).
PJE40 3:7: T HE OBJECT-ORIENTED DESIGN METHODOLOGY MAINLY CONSIST S OF CLASSES, SUB-
CLASSES AND SUPER-CLASSES, AND LOWER CLASSES INHERIT FROM UPPER CLASSES (SAAD, 2010)
This also mentions about the two phases, which occur within Object-Oriented Design, and these two
phases are Analysis and Design (Saad, 2010). This gives examples of which “Computer-Aided System
Engineering (CASE) tools” (Satzinger, Jackson, & Burd, 2005), and these can be used for analysing
the different scenarios (Saad, 2010).
Object-Oriented Design allows the developer to use a wide range of “Computer-Aided System
Engineering (CASE) tools” (Satzinger, Jackson, & Burd, 2005) to help utilise the organisation of the
project tasks in hand. Satzinger lists all of the CASE tools in his book, Object-Oriented Analysis &
Design with the Unified Process. Amongst these tools, Satzinger mentions about, “Use Cases, classes,
subsystem packages, design patterns, class tables and so much more” (Satzinger, Jackson, & Burd,
2005).
“There are many options for object-Oriented
programming”
Some of the CASE tools may not be appropriate
for the project tasks in hand.

PJE40 3:8: T HE GENERAL ANALY SIS OF OBJECT -ORIENT ED DESIGN COMPARES T HE MAIN
ADV ANT AGE W IT H T HE MAIN DISADV ANT AGE (SAT ZINGER, JACKSON, & BURD, 2005)
However, considering this, some of the CASE tools available to the developer may not be appropriate
for the project tasks they are trying to undergo. Tools such as the classes and the subsystem
packages, may only be useful for certain tasks, but not for others. Satzinger lists the tools in his book
Object-Oriented Analysis & Design with the Unified Process, but he lists them according to the
relevance of the project tasks (Satzinger, Jackson, & Burd, 2005).
THE TWO PROJECT MANAGEMENT METHODOLOGIES
This section analyses the structure, advantages, and disadvantages of two project management
methodologies; these include The Prince2 Method, and The Dynamic System Development Method
(DSDM). The analysis focuses on the comparison of the advantages and disadvantages, and shall
present the contrasts in a table.
THE PRINCE2 METHODOLOGY
The structure of The Prince2 Methodology consists “four different sections that help tailor any kind of
project” (Prince2, 2007). A web site, which focuses on The Prince 2 Methodology, explains about each
of the six variables involved in each project, “There are six variables involved in every project and
therefore six aspects of project performance to be managed” (Prince2, 2007). Figure 3:9 gives a
more generalised view of The Prince2 Methodology
PJE40 3:9: T HE PRINCE2 MET HODOLOGY IS ORGANISED IN A CY LINDROMIC GRAPH, W HICH
ENSURES BET T ER QUALIT Y AND ORGANISAT ION (PRINCE2, 2007).
Scroll UK lists some of the main benefits that The Prince2 Methodology offers, and the main benefits
mentioned in this website include, “a more controllable and organised start, middle, and end. This
also gives organisations regular reviews of progress against plan, and reviews of progress against a
specific Business Case” (Scroll Methods, 2009). Figure 3:10 shows the comparison of the main
advantage with the main disadvantage.

The Prince2 Methodology offers a more
controllable and organised start middle and end
This methodology may struggle to meet the
needs of other project management
methodologies
PJE40 3:10: T HE GENERAL ANALY SIS OF T HE PRONCE2 MET HODOLOGY COMPARES O NE MAIN
ADV ANT AGE W IT H ONE MAIN DISADV ANT AGE (SCROLL MET HODS, 200 9).
However, there are also some disadvantages of managing a project with Prince2; Tutorials Points, a
website looking into this project management methodology points out that, “When it comes to
disadvantages, Prince2 does not offer the level of flexibility offered by some of the modern project
management methodologies. This methodology may also struggle to meet some of the needs of other
project management methodologies” (Tutorials Point, 2013).
THE DYNAMIC SYSTEM DEVELOPMENT METHOD
The way that The Dynamic System Development Method works, is that it is a straightforward
framework, to manage the principles of managing a project. This organises tasks over functionality,
time, and resources (AGILE: DSDM, 2011). This also explores through the different phases of
Dynamic System Development Method over Traditional Methods. This method uses The Moscow
Prioritisation Model, which helps with the analysis of the user requirements (AGILE: DSDM, 2011).
Figure 3:11 gives a more generalised view of The Dynamic System Development Method.
PJE40 3:11: T HE DY NAMIC SY ST EM DEV ELOPMENT MET HOD P RIORIT ISES T ASKS OV ER
FUNCT IONALITY , T IME, AND RESOURCES. T HIS USES T HE MOSCOW PRIO RIT ISAT ION MODEL,
W HICH HELPS W IT H T HE USER REQUIREMENT S (AGILE: DSDM, 2011).
The advantages of using The Dynamic System Development Method, includes the insurance of having
a method of prioritisation taking place. This allows the developer of the team to set the priorities
straight. (AGILE: DSDM, 2011). This uses The MoSCoW prioritisation method, and works out to be the
best model, as you can organise each element of a project to go into each category of the acronym.
This organises the different elements into Must Have, Should Have, Could Have, and will not have
(Coley Consulting, 2001). Figure 3:12 shows the comparison of the main advantage and the main
disadvantage.

“The Dynamic System Development Method
allows the developer to prioritise each possible
element of a project”
“The Dynamic System Development Method has
high barrier entries, the inflated costs of licencing
and the cultural shifting of organisation “
PJE40 3:12: T HE GENERAL ANALYSIS OF T HE DY NAMIC SY STEM DEVELOPMENT METHOD COMPARES
ONE MAIN ADV ANT AGE W IT H ONE MAIN DISADV A NT AGE (AGILE: DSDM, 2011)
There are several disadvantages of using The Dynamic System Development Method, and a website,
which specialises in The Dynamic System Development Methods list them out in an efficient way. This
website points out that, “There are three disadvantages of using The Dynamic System Development
Method; these include the licencing costs, the barrier entry is relatively high and the cultural shift of
organisation” (AGILE: DSDM, 2011).
THE FINAL CHOICE OF METHODOLOGY
Based on the analysis conducted on the six methodologies, the decision arose that The Maths
Program follows The Waterfall Methodology. This is because the developer can iterate a loop more
easily. This is especially helpful when designing a program requiring multiple tests per feature. Figure
3:13 gives a generalised view to this revision of The Waterfall Methodology.
PJE40 3:13: T HIS V ERSION OF T HE W ATERFALL METHODOLOGY INCLUDES A ST AIRCASE, W HICH
ALLOW S T HE USE OF RECURSIV E FUNCT IONS (LEST ER, 2011)
This version of The Waterfall Methodology features a staircase, because this iterates the loop that
allows The Maths Program to have its features tested, one at a time. Based upon the research that
The Waterfall Methodology is suitable for educational programs; this will be of a huge benefit to The
Maths Program, as it tests the looped processes as per feature. Additionally, as the Waterfall
Methodology is suitable for smaller projects, this is best suited to The Maths Program, as it is little
programs all bundled up into a bigger compilation of applications. The reason that The Waterfall
Methodology is appropriate for The Maths Program is because it is easier to get the stages in the
correct sequence than it is for The Spiral Methodology. As The Spiral Methodology is more suited to
higher risk projects, The Maths Program is therefore too basic for such a methodology. With The
Waterfall Methodology, it is easier to “back-phase” if anything goes wrong with the project tasks in
hand.

CHAPTER 4 – THE REQUIREMENTS
This chapter looks at the requirements of The Maths Program, and these requirements include user,
functional, technical, and the requirements that focus on Human Computing Interaction. The user
requirements focus on the requirements requested by the human subject. The functional
requirements focus on the requirements requested by the application to ensure it runs at full capable
levels. The technical requirements focus on the requirements needed by the Operating System,
amongst these includes the appropriate framework. Other requirements include Human Computer
Interaction; these include the different functions to ensure feasible use by disabled persons.
THE USER REQUIREMENTS
The typical users using The Maths Program are children between the ages of seven and eleven. The
Microsoft Developer Network suggests that using a requirements model, as it “helps you to focus,
describe, and define the user requirements” (The Microsoft Development Network, 2012). This table
analyses the different skills of a typical child, and looks at what The Maths Program will offer. This
helps the child to fulfil their challenge. Figure 4:1 looks at some of the skills developed by children of
KS2.
Year Ages Number Roman Numerals Money
3 7 – 8 Up to 1,000 Up to L (50) Up to £51
4 8 – 9 Over 1,000 Up to M (1,000) Up to £102
5 9 – 10 Up to 10,000 Over M (1,000) Over £103
6 10 – 11 Up to millions Over M (1,000) Over £104
PJE40 4:1: IXL MAT HS ANALYSES T HE DIFFERENT SKILLS OF SECOND KEY ST AGE CHILDREN, AND
LIST S T HE SKILLS T HEY DEV ELOP OV ER T HOSE Y EARS (IXL UK: MAT HS, 2013 ).
Based on the Diagram illustrating the skills of the user, it is important to ensure that The Maths
Program meets the needs of the typical user. To ensure this happens, the design of The Maths
Program will have:
1. Maximum caps: This ensures that the program doesn’t go out of the scopes for children of
the Second Key Stage
2. Challenging aspects: This will help enhance on any Maths skills that the child may have
developed during their First Key Stage
3. A bundle of small calculators instead of a big one: This will help the child to enhance on the
specific skill builder in which is their weakest point first
However, after speaking to some of the testers, Tester 1 said that they could only count up to 100,
whilst Tester 2 said that they could only count up to 200. Considering this, the maximum number of
The Maths Program shall be 20% of what a typical child of Year 3 would normally learn (i.e. up to
200 instead of up to 1,000).
THE FUNCTIONAL REQUIREMENTS
1
(IXL UK: Year 3 Maths, 2013)
2
3
4

The functional requirements look at the external software required, and these ensure that The Maths
Program is able to function properly. To ensure that it is possible for The Maths Program to follow the
functional requirements, The Moscow Prioritisation shall look at The Maths Program and its features,
and determine what is possible, and what is not. Coley consulting points out that, “A more successful
method is to prioritise requirements by using words that have meaning. Several schemes exist but a
method popularised by the DSDM community goes by the acronym Moscow” (Coley Consulting,
2001). Figure 4:2 gives a more general view of what can (or cannot) feature due to time and budget
The Moscow Prioritisation Model: The Maths Program
Must have Should have Could have Will not have
 Mini programs which
are easy, so that
 KS2 children are able to
complete the tasks with
ease
 Sensible limits must
also be in place
 Due to a recent talk with
the human subjects, the
maximum number is to
be capped at 200
 A series of intuitive
animated videos:
 To be organised in a
fully flexible Tutorial
Centre
 A bundle of small
calculators instead of a
big one:
 This ensures ease of
completing skill building
tasks
 Voice activated
message boxes
 This has the
message text being
read out to the child
 A series of
converters
 Helps the child to
convert between
different currencies,
temperature and
weights
 Any mini program
which is not doable,
due to
 Time constraints
 Lack of programming
skills
 Lack of budget
PJE40 4:2: T HE MOSCOW PRIORIT ISAT ION MODEL FOR T HE MAT HS PROGRAM SHOW S W HAT
FEAT URES CAN (OR CANNOT) BE FEATURED, BASED ON T HE PRIORITISATION, BY MEANS OF T IME
AND BUDGET
Additionally, since Microsoft Visual Studio 2012 is used to design (and code) The Maths Program, it is
therefore important that the machines, which are to have The Maths Program installed on them, have
the .NET Framework 4.5 installed. This helps ensure that The Maths Program is able to function at its
optimum level.
THE TECHNICAL REQUIREMENTS
As a precaution of using Microsoft Visual Studio 2012 to develop The Maths Program, and using .NET
Framework 4.5, it is decisive that the earliest Operating Systems required for The Maths Program is
Microsoft Windows XP. It is currently unknown how much Random Access Memory (RAM) The Maths
Program requires, but you need at least half a gigabyte (512 Megabytes (MB)) in order for Microsoft
Windows 7 to run at a basic level. The hard disk space required by The Maths Program can be
anything up to 100 MB, and the disk space required to run Microsoft Windows 7, can be anything up
to 15.0 GB.

THE HCI REQUIREMENTS
Based upon the research conducted on the literature review (see – The Literature Review for more
detail), the requirements based on the Human Computer Interaction are the vital ones, as human
subjects with disabilities should be able to use this without any difficulties.
ACCESSIBILITY REQUIREMENTS
In order for The Maths Program to be fully accessible, it has to follow different requiremen ts set out
by The W3C/WAI. The main text within The Maths Program will have a size of at least 24; this allows
users with limited sight to see the numbers properly. The Maths Program will also have an
appropriate colour scheme, for example, if you were to have a light coloured interface, the text
should be black, or if you were to have a dark coloured interface, the text should be white. However,
if you are disabling buttons as you are coding the artefact, you should have a dark coloured interface
with white text. This will ensure the users know which buttons are disabled, an d which ones are not.
Figure 4:3 shows the layout of The Division Calculator, and looks at the accessibility side of the
program.
PJE40 4:3: IT IS MUCH EASIER T O DET ERMINE T HE ST A T E OF EACH BUT T ON. W HEN A HUMAN
SUBJECT PUTS “13” IN T HE DISPLAY NUMBER BOX, IT SHOWS T HAT T HEY CAN NOW ONLY PUT “2”
T O T HE ST RING T O GET “132”
USABILITY REQUIREMENTS
In order to produce a fully working Maths Program, the whole of the program must not contain any
errors. There are eight different rules for usability, and Schneiderman describes these as his “golden
rules” (Schneiderman, 2013). Schneiderman also explains about each of his golden rules, and points
out that to produce a fully usable interface; you must “Strive for consistency, enable frequent users
to use shortcuts, offer informative feedback, design the dialog to yield closure, offer simple error
handling, permit easy reversal of actions, support internal locus of control and reduce short-term
memory load” (Schneiderman, 2013).

CHAPTER 5 – THE DESIGN
This chapter explains about the designing of The Maths Program, and explores through the different
stages of design. This looks into the history of the design, and includes low-fidelity and high fidelity
shots of what The Maths Program looked like throughout the different versions.
THE ALPHA VERSIONS
The welcome screens of these versions of The Maths Program mainly consist of buttons and labels,
and a little bit of basic coding. The colour scheme was set at its ultimate default and the main text
was Segoe MT. The font face used for the main programs within The Maths Program was Helvetica
LT Standard, and the font size was 36. Figure 5:1 gives a general picture of what version zero of The
Maths Program looked like in low-fidelity mode.
PJE40 5:1: T HIS IS A LOW -FIDELITY SHOT OF T HE MATHS PROGRAM, DURING IT S ALPHA ST AGES
OF DEV ELOPMENT
Both of the alpha versions (zero and one) followed suit with the low-fidelity shot; the buttons sat
underneath the corresponding labels based upon their purpose. However, when it came to upgrading
to version two, this saw the reorganisation of all buttons on the welcome screen. This provides a
somewhat easier way to point people in the right direction as to what game, practical or quiz which
they wanted to participate. Figure 5:2 shows a more high fidelity shot of The Maths Program, and this
is version one of the welcome screen.

PJE40 5:2: T HIS IS T HE HIGH FIDELIT Y FORM OF T HE MAT HS PROGRAM, T HIS FOLLOW S T HE
ST RUCT URE OF V ERSION ZERO (0).
However, version one (1) saw the scheduling of the first maintenance check, and this included the
tidying up of the code, which then sees the code organised into different categories, which were then
organised by area of the form itself.
THE BETA VERSIONS
The second version of The Maths Program was the first in the Beta series. Whilst this was the case,
the maintenance of the previous version organised the buttons of the welcome screen into more
categorical groups where relevant. The next two figures show the comparisons of the welcome
screen (in the style of version two), and more explanation follows, as to how the groups and buttons
were then removed from The Maths Program. Figure 5
PJE40 5:3: T HIS IS T HE LOW-FIDELITY SHOT OF T HE MATHS PROGRAM, W HILST IN V ERSION T W O
(2) T EST ING
Whilst version two of The Maths Program has this layout for the welcome, the rest of the forms
stayed the same in their layouts. Figure 5:3 saw the original layout through the low-fidelity shot,
whilst the main form itself differs somewhat from the sketch of Figure 5:3. This version also saw the
dropping of the “Number Groups” game, and this was due to lack of programming knowledge. Figure
5:4 this shows the second version of the welcome screen for The Maths Program.

PJE40 5:4: V ERSION TWO OF T HE W ELCOME SCREEN OF T HE MAT HS PROGRAM FOLLOW S T HE
ORGANISING OF ALL T HE BUT T ONS INT O T HEIR APPROPRIAT E GROUPS.
However, big things happened to the design of The Maths Program, when it upgraded to version
three (3). Improvements included a change of colour to all forms, and everything in the main form
now has their own groups. This also saw the condensing of font face throughout the whole program,
and saw a brand new menu strip replace the entire button collection on the welcome form. This
offers the opportunity to provide a more interactive Windows-esque feel to The Maths Program.
Figure 5:5 shows a low-fidelity shot of the welcome screen of The Maths Program, which stayed in
version four as well.
PJE40 5:5: V ERSION T HREE OF T HE W ELCOME SCREEN OF T HE MAT HS PROGRAM SHOW S T HE
MENU ST RIP AT T HE BO T T OM, W HICH HAS REPLACED ALL OF T HE BUT T ONS ON T HE SCREEN
This showed a great improvement all over The Maths Program, and version four puts this under a
second maintenance check. This further improved the quality of The Maths Program in a similar way
to version one. However, this did not reintroduce the groups present in version one. Figure 5:6 shows
you a high fidelity screen shot of The Maths Program, whilst in version three (and four).

PJE40 5:6: T HIS IS T HE HIGH FIDELIT Y SCREEN SHOT OF V ERSION T HREE OF T HE MAT HS
PROGRAM, AND T HE MENU ST RIP AT T HE BOT T OM OF T HE SCREEN HAS REPLACED ALL T HE
BUT T ONS AND T HEIR GROUPS.
THE FINAL VERSIONS
This is the high fidelity screen shot of version three of The Maths Program, and the menu strip at the
bottom of the screen has replaced all the buttons and their groups. These include another change in
the colour scheme, a change of font face, brand new features added to the main programs, the
introduction of message boxes, and the introduction to life counters, score trackers, and question
cappers. This also included a whole range of new games, a bundle of calculators and convertors, and
even includes a clock in the bottom right hand corner of the screen. This also saw the practicals and
quizzes group together to form a new “exercises” tab, as well as vast improvements to the games
group. Figure 5:7 shows a low-fidelity screen shot of the current version of The Maths Program, and
every practical, quiz and game, now have an opportunity to score up to 3,000 points, and have 10
questions per round. The Maths Program awards the player with 20 points for every life they have
remaining, in which they start with 15 in each round.
PJE40 5:7: T HIS IS T HE LOW-FIDELITY SHOT OF T HE W ELCOME SCREEN OF T HE MATHS PROGRAM
(CURRENT V ERSION), AND HAS HAD A FAIR A MOUNT OF IMPROV EMENT S SINCE V ERSION ZERO
The sixth version of The Maths Program is the latest in the final testing, and this undergoes final
maintenance checks. This also undergoes another font change, and sees the enlarging of fonts in the
menu strips from nine to 15. Additionally, this will not go by version six, but version 10, as everything
rounds up nicely. The decision of the font enlarging arose due to some of the testers finding it
difficult to read from size 9. The font change ensures easier readability for younger children;
however, they may need to download the font first. Figure 5:8 shows the high fidelity of the current
version of The Maths Program; however, as it is currently under construction, there are two different
colours showing on the welcome screen.

PJE40 5:8: T HE CURRENT V ERSIO N OF T HE MAT HS PROGRAM IS ST ILL UNDERGOING IT S
MAINT ENANCE CHECK, A ND T HE PROT OT Y PING O F T HE EXT RA FEAT URES
Additionally, this version includes new features; these include the ability to use the calculator from
within the practicals and quizzes. This decision arose due to several testers finding the questions
difficult and needing the extra help. This maintenance check also simplifies the questions in the
practicals and quizzes, with the integration of the calculator, in which the child uses, should they be
stuck on a question.
THE SUMMARY
The main changes that occurred in the designing of The Maths Program, was the colour change. This
was because light text on a dark background works best for those who are colour-blind. Additionally,
the text in the Alpha version was Helvetica, as this was the best font at the time. However, the beta
compresses this, so that more digits would fill the group. When it came to version five, the colour
scheme changed to a deep sky blue with black text originally. However, since the testers did not
know which buttons worked, and which ones did not, the text colour changed to white (please look
back at chapters two and four for more details). The text size in the latest version also changed, as it
was more difficult for a child to see text in size 9 Segoe than it is for them to see size 14 Myriad Pro.
Therefore, the font type changes once again, and figure 5:9 shows the comparison of these two text
sizes.

PJE40 5:9: T HE T OP PART OF T HE PICT URE IS V ERSION T HREE, W ITH T HE FONT SET T O SEGOE UI
AND AT SIZE 9, W HILST T HE BOTTOM PART OF T HE PICTURE SHOWS V ERSION FIV E (CURRENT LY
UNDER CONST RUCT ION) W IT H T HE FONT SET T O MY RIAD PRO AND AT SIZE 14.

CHAPTER 6 – THE PROTOTYPING
This chapter looks at the coding behind The Maths Program, and justifies why it happened. The
sections look at each of the features broken down into each category. These features focus on every
practical, quiz, game, converter and calculator included in The Maths Program. All figures of The
Maths Program are from version zero, and they feature in the Appendix.
THE PRACTICALS
The practicals started as number generator, which would give out sums at random. This allowed the
child to write down the sums generated, and click on the next question button when successfully
completed. However, this did not take into account that the child (more often than not) counted in
their head, and whilst this showed a good starting point, the number ge nerators proved to confuse
the child, and they found any future sums difficult. Figure 6:1 gives a generalised view of what the
practicals looked like.
PJE40 6:1: T HE BETA OF T HE ADDITION PRACT ICAL LOO KED JUST LIKE A NUMBER GENERAT OR
GIV ING OUT T W O NUMBERS FOR CHILDREN T O A DD
This layout stayed throughout the first four versions of The Maths Program, and in the fifth version,
this included a text-box for input, and the maximum number of questions (set to 10 throughout the
whole of The Maths Program). This helped to provide better interaction with the children.
Additionally, this gives out encouraging messages if the child answers incorrectly.
THE QUIZZES
The quizzes originally provided very basic interaction with the children, and included the same
number generators and the three buttons (next, check and close). This also gave out messages at the
bottom of the user input box, and this changed colour dependent upon the answers given at the
time. Still, this required the child either to write the numbers down, or to use mental arithmetic, and
both can prove quite difficult. Figure 6:2 gives you a general view of a quiz about to take place.

PJE40 6:2: T HE ADDIT ION Q UIZ OFFERED T HE CHILD V ERY LIT T LE INT ERA CT ION DURING IT S
BET A ST AGES
These kept to their original layout until the fifth version, where The Maths Program saw the
introduction of message boxes throughout the whole of the program. Additionally, this also
introduced maximum number of questions (10 throughout the whole of The Maths Program), this also
gives the child extra room for error (15 lives per round), and offers them with the ability to score
points (up to 3,000 per round). This also provides different messages to the child, whether they have
answered correctly or incorrectly.
THE GAMES
The beta development stages of The Maths Program only included two games in its rather small
package, and these were “Find the Answer” and “Bigger or Smaller”. Find the Answer gets the child
to fill the gap in the sum (example, what goes with 100 to make 200). Bigger or smaller gets the child
to compare two different, and asks, “Is the first number bigger, smaller, or the same”? Figure 6:3
gives a general idea of how bigger or smaller looked like during its beta stages.
PJE40 6:3: T HE BETA STAGE OF BIGGER OR SMALLER ALLOWS Y OU T O CLICK A BUT TON, BUT T HE
CHILD MAY FIND T HE SY MBOLS CONFUSING
During the development of the final version, this offered more interaction with the child. Like the
other features of The Maths Program, this includes lives, question rounds and the opportunity to
score points. Additionally, this also saw the replacement of the buttons with smart menus, which
disable themselves whenever someone answers incorrectly. This prevents them from making the

same mistakes twice during the same question, and thus limits the number of lives lost per question
to two.
THE DEPRECATED FEATURES
The Maths Program also saw the deprecation of a couple of converters due to time constraints, and a
game due to lack of programming knowledge. The Maths Program originally consisted of five
converters, and these were currency, weight, temperature, length, and distance. The length and
distance converters never had any work done on them, and The Number Groups game was close to
beta staging.
PJE40 6:4: T HE NUMBER GROUPS GAME NEV ER MADE IT PAST IT S INT IAL ALPHA ST AGE DUE T O
LACK OF PROGRAMMING KNOW LEDGE
The Number Groups game originally consisted of five groups, and 10 numbers (numbered one to
ten). This saw a reduction from five groups to three, and the removal of the number 10. This ensures
that the three numbers remaining would definitely not fit into any of the two text boxes in the three
groups. As the child entered the numbers into each of the text boxes, the numbers in the number
group would disable as this limits the use of each number to once per question. If the child then
realises that they made a mistake, they would delete the number from a text box, and this would re-
enable that number so that it becomes available for another text box.

CHAPTER 7 – THE IMPLEMENTING
This chapter looks at the implementation behind The Maths Program, looks at the problems
encountered during implementation, and how the solutions taken to overcome each problem. This
also explains about the implementing issues behind The Number Groups game, which eventually
resulted in its withdrawal from The Maths Program.
THE IMPLEMENTATION METHOD
The implementation method focused on every change made to each feature of The Maths Program.
This ensures that every feature worked at its 100% optimum with no bugs causing runtime errors.
The implementation method also tested each of the design aspects as they changed. The Maths
Program was designed and prototyped using Microsoft Visual Studio 2012 Ultimate, and was
programmed using Visual Basic. Figure 7:1 shows you the welcome screen of Microsoft Visual Studio
2012 Ultimate.
PJE40 7:1: T HE MATHS PROGRAM W AS DESIGNED AND PRO T OT Y PED USING MICROSOFT V ISUAL
ST UDIO 2012 ULT IMAT E
PROBLEMS ENCOUNTERED
The Maths Program encountered several bugs during implementing, and these were mainly run-time
errors. These errors occur during the execution of the program, and most often appear when during
the maintenance of all practicals and quizzes, including empty text-boxes that should contain a
number. The main problem includes the removal of features from a dialogue form and failing to
adjust the code. The most common run-time problem includes trying to perform a conversion from a
string to a double during debug. The main problem occurring during the maintenance of the
practicals and quizzes includes failing to code calculators properly thus resulting in negative numbers
(i.e. -40) and decimal points (i.e. 10.5). Other problems maintaining practicals and quizzes include
failing to organise the message boxes correctly thus you stay in the same part of the round, and
failing to duplicate the number generators thus resulting in getting the same question throughout the
whole round.
Additionally, if you put a program in state as you initialise it, this could result in problems when you
try to load the same form the second time round. This is due to the forms remembering the data
entered from the previous. Other problems include the disabling of all the features when you load the
form the second time round, because this prevents you from having another go at that feature.
Please refer to PJE40 6:4, as these errors in particular affected the implementation of The Number
Groups game.

THE SOLUTIONS
This section looks at how The Maths Program overcame all of the problems encountered during its
implementing stage. More often than not, this mainly involved tweaking the code to add (or remove)
features to the artefact itself. Figure 7:2 gives a general idea of what happened behind the coding of
The Division Calculator, and how this overcame its problems.
PJE40 7:2: T HE DIV ISION CALCULAT OR W AS ONE OF T HE MOST DIFFICULT PROGRAMS T O
IMPLEMENT , DUE T O UNFORSEEN PROBLEMS
However, due to the solutions taking place, mainly working with the times-table during the
implementing of The Division Calculator, this was successful through both prototyping and
implementing stages. However, The Number Groups game was not quite successful during its
implementing run.
The Division Calculator had to have the times-table typed out for each number in the second group
(e.g. for the availability of the number two, the numbers are 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22 and
24). This ensured the avoidance of decimal numbers at all times (e.g. upon typing 110, only number
10 and 11 should be available).
Additionally, since the program suffered major build errors, which were preventing successful
execution of The Maths Program, this led to code alteration. Nevertheless, as the alteration of coding
increased, the chances of successful execution of The Maths Program decreased. This ultimately led
to the withdrawal of the Number Groups game from The Maths Program, due to lack of programming
knowledge and too many bugs in the program.
Additionally, in version five, there was a big calculator originally, so that children can type in any
number of their choice. However, due to unforeseen errors within the prototype, this became a
bundle of four small calculators. This worked out better for the children, as they can now focus on the
operations they struggled with most.

CHAPTER 8 – THE TESTING SESSIONS
This section explains about the testing behind The Maths Program. The development of The Maths
Program saw two testing sessions organised with the human subjects. These took place during the
beta stages of The Maths Program, and the second testing session saw the human subjects’ complete
tests against the clock.
THE FIRST TESTING SESSION: DECEMBER 2012
During both testing sessions, the human subjects took part in completing a few tasks during the test
run of The Maths Program. The first testing session took place with no time limits in place; this
helped each user understand what The Maths Program is, and how it works. Additionally, so that
each user understood about The Maths Program, they both worked together during this testing
session. Additionally, it worked out that the favourite section of The Maths Program at that time was
the game “Bigger or Smaller”. The testers enjoyed it that much, that after lunch they wanted to have
another go at that game. Figure 8:1 shows you what The Maths Program looked like during the first
testing of The Maths Program.
PJE40 8:1: T HIS W AS W HAT GREETED T HE USERS DURING T HE FIRST T EST ING SESSION. MANY
IMPROV EMENTS T OOK PLACE SINCE T HE FIRST T ESTING SESSION; ONE OF T HEM IS T HE CLOCK.
THE SECOND TESTING SESSION: FEBRUARY 2013
The second testing session tested the subjects against the clock. Each human user completed three
tasks; these included answering three different adding questions during a practical, complete a whole
round of “Bigger or Smaller”, and convert three different temperatures with the conversion of their
choice. Each subject took between 90 seconds and 5½ minutes to complete each task. Figure 8:2
gives you a general user analysis, which shows how long it took each user to complete each task.

PJE40 8:2: GENERALLY, T HE HUMAN SUBJECTS T OOK BETWEEN 90 SECONDS AND 5½ MINUTES T O
COMPLET E EACH T ASK
The difficulties that both subjects faced saw the integration of the calculator into the practicals and
quizzes. This tab presents them with a calculator where they can enter the two numbers, see the
answer, and type it in the appropriate dialogue box. Figure 8:3 shows you the state of the welcome
screen during the second testing session.
PJE40 8:3: T HIS W AS W HAT GREETED T HE HUMAN SUBJECT S, W HEN T HEY FIRST OPENED T HE
MAT HS PROGRAM. HOW EV ER, FOLLOW ING ADV ICE FROM T HEIR PARENT 5
, T HIS SAW T HE
SCHEDULING OF ANOT HER MAINT ENANCE CHECK.
During the second testing, there was a great amount of help offered to the human subjects, and
great deals of encouragements. This was because of the tense environment at the time, and because
the parent was watching at the time, the tests were place. This also ensured that the testing session
5
This happened, because both of the human subjects were less than 16 years of age. You’ll find a
copy of the consent form in Appendix B

ran as smoothly as possible, and that the parent was there to help the human subjects with their
tests.
THE RISK ANALYSIS
The risk analysis tests features of The Maths Program, completes a task, gives an expected result,
records what it did, and explains about whether or not it fully worked. The risk analysis gives a
general suggestion as to what improvements could take place, for the future builds of The Maths
Program. Figure 8:4 gives you the full listed Risk Analysis, and the tasks’ general analysis.
Feature
Name
Task Name Expected
Result
Actual
Result
Did it
Work?
Other Comments
The Addition
Calculator
To perform a basic
calculation up to the
max of 200
Result within max
cap of 200
Result equal to 200

This was due to maximum number
being 100 on both sides
The Division
Practical
To bring up the
calculator within a
question
Calculator shows up
when the button is
clicked
The calculator is
shown when the
button is clicked

This is the multiplication
calculator, as this zeros out any
chances of encountering decimals
The Addition Quiz To start with a
decent number of
lives
To start with at least
10 lives at the start
of the round
Live counter equals
15

This was initially 10, but to offer
more room for error, this was then
raised to 15
The Money Games To prevent child
from over-spending
To disable different
change buttons
based on the
amount of money
given.
The £2 and £5
change buttons
were disabled, as
the child only had
£2 to spend

If the child has less than £5, the £5
change button is disabled.
However, when they only have £1
to spend, the £1, £2 and £5 change
buttons are disabled
The Currency
Converter
To show three
different
conversions
To show at least
three different
currencies
Three different
currencies are
shown

Because this shows rates at $1.61
and €1.23 to the £1, The Currency
Converter shows $1,610 and €1,230
to £1,000
PJE40 8:4: T HIS SHOW S T HE RISK ANALY SIS, AND ANALY SES T HE PERFORMANCES ON FIV E
DIFFERENT FEAT URES O F T HE MAT HS PROGRAM

CHAPTER 9 – EVALUATING AGAINST REQUIREMENTS
This chapter evaluates the different features of The Maths Program and compares them with the
original requirements set out in chapters two and four. This evaluates the analysis of the
requirements even further, and determines whether The Maths Program fully meets these
requirements. These requirements mainly focus on usability and accessibility.
THE MATHS PROGRAM: USABILITY
Based upon the usability requirements set out in Chapter 4 (– The Requirements), The Maths
Program has contrasting colour schemes, which allows the user to determine the state of the buttons,
whether enabled or not. Additionally, following the rules of Schneiderman, this follows in consistency,
because all answers boxes have “check” and “calculator” included (Schneiderman, 2013).
The textboxes change colour prior to input given by the user. If the user answers correctly, the colour
of the textbox goes green. If the user answers incorrectly, the colour of the text box goes red.
However, if the state of the textboxes were set to read only, the colour of the font would change. If
the user answers correctly, the font colour goes green. If the user answers incorrectly, the colour of
the font goes red.
THE MATHS PROGRAM: ACCESSIBILITY
This section focuses on the accessibility aspects of The Maths Program and determines whether this
meets the requirements that make an artefact accessible for someone with difficulties. The Maths
Program has the appropriate contrasting colour schemes, as the colour of all dialogue boxes is a deep
sky blue and the text colour is white. This helps determine the state of the buttons, and is particularly
helpful when the subjects use The Division Calculator. An inaccessible artefact would have clashing
colour schemes (e.g. white text on light background, or black text on dark background).
THE MATHS PROGRAM: DOES THIS MEET THE REQUIREMENTS?
Although The Maths Program meets many of the requirements set out in Chapters 2 and 4 (The
Accessibility Requirements: W3C/WAI, Accessibility Requirements and Usability Requirements), this
does not fully meet all the requirements set. Although this offers informative (and encouraging)
feedback to the children, this is very limited and basic in its approach. Additionally, this does not offer
the children with an opportunity to use shortcuts. Then again, since the children’s age range between
seven and eleven, this may not be appropriate.
However, The Maths Program does incorporate the calculator function into all of its practicals,
quizzes, and some of the games. This proves useful, particularly if the child is stuck on a particular
question and they are trying to keep hold of their last few lives. The lives and score also maximises
the interaction available to the child, as they can keep track on how well they are performing.
The Maths Program meets many requirements concerning accessibility. The colour schemes contain
the appropriate contrast, which helps determine the state of buttons. Additionally, the font size
ranges between 12 and 37; the text size of the group boxes reserve size 12, and the number parts of
the question reserves size 37.

CHAPTER 10 – THE CONCLUSION
This chapter looks at the conclusion of The Maths Program by looking at the scheduling, and explains
about whether all tasks in the project were on time. This also concludes about the choice of
methodology, and whether this was the right one. This concludes the entire performance of The
Maths Program, and even suggests new directions as to where this could head.
GANTT CHART: SCHEDULING
A series of meetings with the project supervisor saw the creation of a Gantt chart using Microsoft
Project. This lists the dates of the milestones, and shows their deadline dates. Figure 10:1 shows you
what the Gantt chart looks like, and explains about the organisation of The Maths Program.
PJE40 10:1: T HIS SHOWS T HE ORGANISATION OF T HE MATHS PROGRAM, LISTS T HE MILEST ONES,
AND SHOW S T HE DEADLINE DAT E OF EACH MILEST ONE.
This Gantt chart lists out the 10 tasks scheduled in the second revision. However, the following of the
Gantt chart was not fully successful, due to high levels of distraction and computer maintenance
checks. Additionally, the prototyping was rush-produced at some stages. The rush producing was due
to the approaching testing sessions, and the preference of completed versions of The Maths Program
instead of a half-completed prototype.
THE WATERFALL METHODOLOGY: DID IT WORK?
The Maths Program followed a designing methodology called The Waterfall Methodology. This
restructure of The Waterfall Methodology allowed a staircase to be iterated. The iteration of the
staircase allowed the opportunity to loop the testing of The Maths Program. However, this was not
always successful, due to constant back phasing throughout the development of the main artefact.
Additionally, the development of The Maths Program took off with very little research taken place.
Figures 10:2 and 3:15 both mention The Waterfall Methodology; figure 3:15 explains about The
Waterfall Methodology with a more generalised view, whilst figure 10:2 explains about how it worked
for (and against) the development of The Maths Program.

PJE40 10:2: T HIS IS ANOT HER REMINDER OF T HE W AT ERFALL MET HODOLOGY , IN W HICH T HE
MAT HS PROGRAM FOLLOWED. T HIS ALSO INCLUDES T HE IT ERATION OF T HE ST AIRCASE, W HICH
INDICAT ES A LOOP W IT HIN T HE IMPLEMENT ING ST A GES.
Although The Waterfall Methodology worked to some extent, the staircase within this methodology
caused some hindrance, because it caused the development of The Maths Program to accelerate too
quickly against the research and the write up of the dissertation. However, it also helped, as the
staircase made it easier to follow the different phases within the development of The Maths Program.
Additionally, this staircase allowed for the design of the interface and the system at a parallel.
THE MATHS PROGRAM: CONCLUSION
The Maths Program provided maximum interaction to children of Key Stage Two; however, this still
contains a vast array of bugs. One of the bugs feature in several forms; this happens when you try to
initialise the same form more than once, and it loads the same data from the last question of the
previous round. The only way to solve this bug is to close off The Maths Program, and to reload it
from scratch.
During the beta stages of The Maths Program, the practicals were no more than just generators,
which give you numbers randomly. This changed during version five, as this helps to maximise the
interaction for the children. Some of the mini programs that make up the main artefact were harder
to code, which ultimately led to the withdrawal of The Number Groups from The Maths Program. By
creating The Maths Program, this should help brush up any knowledge on Visual Basic.
Another bug appears in the calculators, this causes the data from the last calculation to remain when
you reopen the calculator. Therefore, the important thing to do is to clearing off all data before
closing the calculator, as this ensures an empty calculator when you access help with answering
another question.
THE MATHS PROGRAM: FUTURE DIRECTIONS
Suggested directions in which The Maths Program face includes a further raise in lives and points. If
the child still struggles at a question, where 15 lives still prove insufficient, this shall rise to 20, where

the child can score 25 points per live. This results in a maximum point cap of 500 per question, which
totals 5,000 per round.
Additionally, The Maths Program will feature some new games, which focus on time, weight, length,
and distance. This shall also include converters that link with the games, and the temperature
converter results will now vary by a unique colour code. If you enter a temperature, which is less
than five degrees (Celsius), the colour of all results will change to blue, and if you enter a
temperature of more than 25 degrees, the colour of all results will change to red.
The Maths Program shall also include different exercises concerning shape and space, and could
include games concerning the organisation of data values. This could include quizzes that focus on
word problems, (e.g. write 1,543 in words, or write four thousand, six hundred and twenty-six in
digits).

REFERENCES
AGILE: DSDM. (2011, August 20). Dynamic System Development Method (DSDM). Retrieved from
AGILE Methods of Software Development: http://dsdmofagilemethodology.wikidot.com/
BBC. (2013). BBC Bitesize: KS2 Maths. Retrieved from BBC Bitesize:
http://www.bbc.co.uk/bitesize/ks2/maths/number/
Coley Consulting. (2001). MoSCoW Prioritisation. Retrieved from Coley Consulting:
http://www.coleyconsulting.co.uk/moscow.htm
I Answer 4 U: Spiral. (2011, December 16). Spiral Model : Advantages and Disadvantages. Retrieved
from I Answer 4 U: http://www.ianswer4u.com/2011/12/spiral-model-advantages-
and.html#axzz2CC8wGk6Y
I Answer 4 U: Waterfall. (2012). Waterfall Model : Advantages and Disadvantages of Waterfall Model.
Retrieved from I Answer 4 U: http://www.ianswer4u.com/2011/11/advantages-and-
disadvantages-of.html#axzz2HbIU1jYf
IXL UK: Maths. (2013). IXL Maths UK. Retrieved from IXL Maths UK: uk.ixl.com
IXL UK: Year 3 Maths. (2013, February 12). IXL Maths UK: Year 3. Retrieved from IXL Maths UK:
http://uk.ixl.com/math/year-3
Learn Access. (2006). The Waterfall Development Methodology. Retrieved from Learn Access with the
Smart Method:
http://www.learnaccessvba.com/application_development/waterfall_method.htm
Lester, C. (2011). Software Engineering: An Introduction (Vol. 1). Portsmouth: University of
Portsmouth.
M@thsZone UK. (2013). M@thsZone UK. Retrieved from M@thsZone UK:
http://www.mathszone.co.uk/
PowerMapper. (1996). SortSite: Accessibility Checker and Validator. Retrieved from PowerMapper:
http://www.powermapper.com/products/sortsite/checks/accessibility-checks.htm
Prince2. (2007). Prince 2 - The Method. Retrieved from Prince2: http://www.prince-
officialsite.com/AboutPRINCE2/PRINCE2Method.aspx
Saad, M. (2010, May). Structured Vs, Object Oriented Analysis and Design. Retrieved from
SlideShare: http://www.slideshare.net/mksaad/structure-vs-object-oriented-analysis-and-
design
Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2005). Object-Oriented Analysis & Design with the
Unified Process. Boston: Course Technology.
Schneiderman, B. (2013). Eight Golden Rules of Interface Design. Retrieved from The Washington
Faculty:

http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.
html
Scroll Methods. (2009, July). Benefits of PRINCE2 (July 2009). Retrieved from Scroll Methods:
http://www.scoll.co.uk/News/Benefits_of_PRINCE2_July_2009.htm
SortSite: BBC Bitesize. (2013, February 1). SortSite: BBC Bitesize Number Analysis. Retrieved from
PowerMapper: http://try.powermapper.com/Reports/90c6cc99-96b5-4dcb-9938-
b1458fdea7fc/report/map.ACC.htm
SortSite: IXL Maths UK. (2013). SortSite: IXL Maths UK Analysis. Retrieved from PowerMapper:
http://try.powermapper.com/Reports/d556beab-ea39-4e37-963c-
49f6d75cdfb7/report/map.htm
SortSite: M@thsZone. (2013). SortSite: M@thsZone. Retrieved from PowerMapper:
http://try.powermapper.com/demo/ViewScan.aspx?id=6843d5d5-3ee5-4033-8e68-
ca9cd5a1e9b3
The Microsoft Development Network. (2012). Modeling User Requirements. Retrieved from MSDN:
http://msdn.microsoft.com/en-gb/library/dd409376.aspx
The Software Development Team. (1988). Spiral Lifecycle Model. Retrieved from SoftDevTeam:
http://www.softdevteam.com/Spiral-lifecycle.asp
Tutorials Point. (2013, January). Prince2 Project Methodology. Retrieved from TutorialsPoint:
http://www.tutorialspoint.com/management_concepts/prince2_project_methodology.htm
Vanderheiden, G., Slatin, J., & Chisholm, W. (2006, April 25). Requirements for WCAG 2.0. Retrieved
from W3C Working Group Note: http://www.w3.org/TR/wcag2-req/

TABLE OF FIGURES
PJE40 2:1: This is the breakdown of the Second Key Stage in all British schools (IXL UK: Maths, 2013)
.................................................................................................................................................... 5
PJE40 2:2: This is the main number page of BBC Bitesize, which covers the basic aspects of Maths,
including fractions, percentages, and place values (BBC, 2013)........................................................ 6
PJE40 2:3: The results show that 45% of the entire collection of number pages from BBC Bitesize has
issues or errors. Results also show that the majority of errors concern Priority "A" (SortSite: BBC
Bitesize, 2013) .............................................................................................................................. 7
PJE40 2:4: If you are a Student in Year 4, this lists the skills that you will learn. Many of these skills
are a step-up from what you would have learnt in Year 3 (IXL UK: Year 4 Maths, 2013). .................. 8
PJE40 2:5: This is the analysis result for the IXL Maths Website. The 63% part is now coloured in red,
as this indicates the severity of the errors detected within this website (SortSite: IXL Maths UK, 2013)
.................................................................................................................................................... 8
PJE40 2:6: M@thsZone gives links to activities on its home page. When the child clicks on one of the
links, they instantly take part in that activity (M@thsZone UK, 2013)................................................ 9
PJE40 2:7: This is the analysis result of the M@thsZone website. These results show that over 50%
of the pages from this website contain errors and issues. Therefore, like the result analysis of IXL
Maths, the number is coloured red. (SortSite: M@thsZone, 2013). ................................................... 9
PJE40 2:8: This is the final summary of the problems each website had, and which priority band(s)
the problems link to (PowerMapper, 1996) ................................................................................... 10
PJE40 3:1: The Spiral Methodology applies to any project with requirements too difficult for any other
model (The Software Development Team, 1988). ......................................................................... 11
PJE40 3:2: The general analysis of The Spiral Methodology compares one main advantage with one
main disadvantage (I Answer 4 U: Spiral, 2011). .......................................................................... 12
PJE40 3:3: Although Winston Royce wrote The Waterfall Methodology in 1970, a wide range of
organisations still use this model for various software projects (Learn Access, 2006)....................... 12
PJE40 3:4: The general analysis of The Waterfall Methodology compares one main advantage with
one main disadvantage (I Answer 4 U: Waterfall, 2012) ................................................................ 12
PJE40 3:5: The Analyst's Approach organises the tasks within the approach, and by the order of how
information is analysed (Satzinger, Jackson, & Burd, 2005) ........................................................... 13
PJE40 3:6: The general analysis of The Analyst's Approach compares one main advantage with one
main disadvantage (Satzinger, Jackson, & Burd, 2005).................................................................. 14
PJE40 3:7: The Object-Oriented Design methodology mainly consists of classes, sub-classes and
super-classes, and lower classes inherit from upper classes (Saad, 2010) ....................................... 14
PJE40 3:8: The general analysis of Object-Oriented Design compares the main advantage with the
main disadvantage (Satzinger, Jackson, & Burd, 2005).................................................................. 15
PJE40 3:9: The Prince2 Methodology is organised in a cylindromic graph, which ensures better quality
and organisation (Prince2, 2007). ................................................................................................ 15
PJE40 3:10: The general analysis of The Pronce2 Methodology compares one main advantage with
one main Disadvantage (Scroll Methods, 2009)............................................................................. 16
PJE40 3:11: The Dynamic System Development Method prioritises tasks over functionality, time, and
resources. This uses The Moscow Prioritisation Model, which helps with the user requirements
(AGILE: DSDM, 2011).................................................................................................................. 16
PJE40 3:12: The general analysis of The Dynamic System Development Method compares one main
advantage with one main disadvantage (AGILE: DSDM, 2011) ....................................................... 17
PJE40 3:13: This version of The Waterfall Methodology includes a staircase, which allows the use of
recursive functions (Lester, 2011) ................................................................................................ 17
PJE40 4:1: IXL Maths analyses the different skills of Second Key Stage children, and lists the skills
they develop over those years (IXL UK: Maths, 2013). .................................................................. 18
PJE40 4:2: The Moscow Prioritisation Model for The Maths Program shows what features can (or
cannot) be featured, based on the prioritisation, by means of time and budget .............................. 19
PJE40 4:3: it is much easier to determine the state of each button. When a human subject puts “13”
in the display number box, it shows that they can now ONLY put “2” to the string to get “132” ....... 20

PJE40 5:1: This is a low-fidelity shot of The Maths Program, during its alpha stages of development 21
PJE40 5:2: This is the high fidelity form of The Maths Program, this follows the structure of version
zero (0). ..................................................................................................................................... 22
PJE40 5:3: This is the low-fidelity shot of The Maths Program, whilst in Version Two (2) testing...... 22
PJE40 5:4: Version two of the welcome screen of The Maths PROGRAM follows the organising of all
the buttons into their appropriate groups. .................................................................................... 23
PJE40 5:5: Version three of the welcome screen of The Maths Program shows the menu strip at the
bottom, which has replaced all of the buttons on the screen.......................................................... 23
PJE40 5:6: This is the high fidelity screen shot of version three of The Maths Program, and the menu
strip at the bottom of the screen has replaced all the buttons and their groups. ............................. 24
PJE40 5:7: This is the low-fidelity shot of the welcome screen of The Maths Program (current
version), and has had a fair amount of improvements since version zero........................................ 24
PJE40 5:8: The current version of The Maths Program is still undergoing its maintenance check, and
the prototyping of the extra features............................................................................................ 25
PJE40 5:9: The top part of the picture is version three, with the font set to Segoe UI and at size 9,
whilst the bottom part of the picture shows version five (currently under construction) with the font
set to Myriad Pro and at size 14. .................................................................................................. 26
PJE40 6:1: The beta of The Addition Practical looked just like a number generator giving out two
numbers for children to add......................................................................................................... 27
PJE40 6:2: The Addition Quiz offered the child very little interaction during its beta stages .............. 28
PJE40 6:3: The beta stage of Bigger or Smaller allows you to click a button, but the child may find the
symbols confusing....................................................................................................................... 28
PJE40 6:4: The Number Groups Game never made it past its intial Alpha Stage due to lack of
programming knowledge ............................................................................................................. 29
PJE40 7:1: The Maths Program was designed and prototyped using Microsoft Visual Studio 2012
Ultimate ..................................................................................................................................... 30
PJE40 7:2: The Division Calculator was one of the most difficult programs to implement, due to
unforseen problems .................................................................................................................... 31
PJE40 8:1: This was what greeted the users during the first testing session. Many improvements took
place since the first testing session; one of them is the clock. ........................................................ 32
PJE40 8:2: Generally, the human subjects took between 90 seconds and 5½ minutes to complete
each task.................................................................................................................................... 33
PJE40 8:3: This was what greeted the human subjects, when they first opened The Maths Program.
However, following advice from their parent, this saw the scheduling of another maintenance check.
.................................................................................................................................................. 33
PJE40 8:4: This shows The Risk Analysis, and analyses the performances on fi ve different features of
The Maths Program..................................................................................................................... 34
PJE40 10:1: This shows the organisation of The Maths Program, lists the milestones, and shows the
deadline date of each milestone. .................................................................................................. 36
PJE40 10:2: This is another reminder of The Waterfall Methodology, in which The Maths Program
followed. This also includes the iteration of the staircase, which indicates a loop within the
implementing stages. .................................................................................................................. 37

Dissertation (Final Version)

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (6)

Similar to Dissertation (Final Version)

Similar to Dissertation (Final Version) (20)

Dissertation (Final Version)