Project Overview

1
Project Overview

• Group 13
• CM10137

2
Milestone One

• The first step was the project plan
• This set out how the group will operate regular
  meetings backed up with an online file store and
  correspondence by email, phone and MSN
• Laid out group resources namely our own skills,
  computer labs and the library along with course
  notes and previous knowledge
• A validation and verification plan was also set
  up at this stage
• A project schedule, shown overleaf, was also
  created

3
(No Transcript)
4

• The next stage was to create a requirements
  document
• We sent out a questionnaire to many people
  receiving answers from 20. These 20 were a mix of
  competent and good users of computers, aged
  between 18 and 66 and a mix in sex.
• From these questionnaires we built up an idea of
  what people wanted from an alarm clock basic
  clock functions, an alarm clock which rings and
  creates a pop-up, an ability to snooze the alarm
  clock and the ability to change alarm tunes. A
  more comprehensive list was obviously created and
  is in the full report.

5

• The table below shows an extract from our
  requirements document
• 3.6.2 The snooze options will be displayed
  in the form of a graphical popup. The user shall
  be presented with the options to snooze or to
  deactivate the alarm. 55 of users suggested the
  snooze reminder be displayed as a popup.
  (Questionnaire Analysis Paragraph 8).

6

• We next created our test and evaluation plan.
  This comprehensively takes each requirement from
  our requirements document and formulates a test
  to perform to ensure that that requirement is met
  by the product
• A section from this is shown below

7

• The final stage of the First Milestone was to
  construct a draft user manual. This was intended
  to get us to think about user interaction.
  However due to our prototyping process anyway
  this had limited use for our project.
• The manual takes the user through each possible
  scenario explaining how to do each of the various
  functions. It is a comprehensive document
  covering every aspect of the program
• A section from the user manual is displayed to
  the side

8
Milestone Two
Design

• The first step towards design was the system
  model
• These models are used for low level explanation
  of System requirements
• The following slide shows our State-Control model

9
(No Transcript)
10

• The next step was the software design choosing
  a method for developing the software
• We decided upon using a exploratory evolutionary
  model against other process models
• This was due to its huge benefits it terms of
  being easy to accommodate change after user
  testing and its use in UI design.
• It also allowed the system to be developed
  incrementally meaning that core functions could
  be developed early. These were then subject to
  testing several times as later features were added

11

• The user interface design was the next step.
• Our original prototype was commented upon by
  users and various components were changed to make
  the program easier to operate i.e. text boxes
  for entering times were removed and replaced with
  spinners to help users enter valid inputs

12

• The final design stage was to complete the
  back-end specification. This sets out what
  classes will be used, the methods in each and the
  flow of data. The diagram on the next slide shows
  the class interactions

13
(No Transcript)
14
Implementation

• Having designed the application it was then
  developed
• We will now have a short demonstration of the
  program

15
Testing and Evaluation

• The next stage of the project was to test and
  evaluate the product. First the program was
  released to some group members who went through
  and tested each aspect of the program. A few
  mistake were found namely that on the drop down
  boxes text could be entered this was not wanted
  so the program was changed so that the user was
  restricted to using the options on the list
• Following on from this the program was released
  for user evaluation

16

• We picked two users one with a large amount of
  familiarity with computers and one without. It
  was decided not to have a large number of users
  as analysing the results would take too much time
• The users were asked to carry out five scenarios
  and comment on each

17

• 1) Add an alarm set to go off in 1 minutes time
• Wait for the alarm
• Close the alarm
• 2) Change the snooze time to 1 minute
• Add an alarm set to go off in 1 minutes time
• Wait for the alarm
• Snooze the alarm
• Wait for the alarm
• Close the alarm
• 3) Add an alarm set to go off in 1 minutes time
• Add an alarm set to go off in 5 minutes time
• Add an alarm set to go off in 10 minutes time
• Wait for the first alarm
• Close the alarm
• Change the alarm tune
• Wait for the second alarm
• Change the third alarm to go off in 1 minutes
  time
• Wait for the third alarm

4) Add an alarm set to go off in 5 minutes time
Add an alarm set to go off in 10 minutes time
Delete the 10 minute alarm Delete the 5
minute alarm 5) Try to create an alarm at
246060 Try to create 11 alarms
18

• The major fault found with the application was
  that if an alarm was already open and another
  alarm went off the second alarm did not appear.
• This was something that we had not considered
  when programming the application.
• It was decided, after consultation with the two
  users, that opening a new window for each alarm
  would annoy users. Instead it was agreed to
  remove the first alarm and show the second when
  the second alarm went off. The users found this a
  successful fix
• After the program was changed the users had no
  faults with the new application

19

• Having completed the testing a new User Manual
  had to be created
• This goes through every scenario and guides the
  user through using the application
• The manual is comprehensive and covers every
  function of the application
• A sample screenshot is shown overleaf

20
(No Transcript)
21

• The very final stage of the project was the
  program documentation
• This is intended to be the basis for a
  maintenance document.
• The first stage is a UML document, similar to
  that in design, showing how the classes interact
• The second stage is a list of what each class
  does and what each method within the classes does
• The third stage was to document the variables
  within the program and explain what they are for

22
(No Transcript)
23

• Two extracts from the class listing showing the
  main class and the use of the snooze variable
• UClass the main class for the program. Acts as
  the driver. Displays the clock and details of
  what alarms are set, the current snooze time and
  the current alarm tune set.
• Tick this method occurs every second when the
  timer changes. Updates the clock and checks to
  see if an alarm needs to ring
• Close this method closes the application
• EditClick this method opens the about screen
• SetalarmClick this method opens the SetAlarm
  Screen
• SettuneClick this method opens the SetTune
  Screen
• HelpClick this method opens the help box
• SetsnoozetimeClick this method opens the
  SetSnoozeTime screen
• FormCreate this method is called when the
  program is created. Initialises all the variables
  in UVariables
• ChangeAlarmClick this method opens the
  ChangeAlarm screen
• DeleteAlarmClick this method opens the
  DeleteAlarm screen
• The snooze variable is of type integer. It holds
  the length of time in minutes that the alarm
  should snooze for if requested. As it is only in
  minutes an integer is more appropriate than a
  string. This can simply be added onto a decoded
  alarm to work out when the next alarm should be
  set for.

24
The End!Thank you for listening