Year 11 Assessment Task

Software Design and Development – Preliminary Course

Weighting:10%

Issued Date:Monday 14th August 2006

Final Part Due:Monday 4thSeptember 2006

Unit:8.2 Building Software Solutions

1Outcomes

A student:

P1.2describes and uses appropriate data types

P4.2investigates a structured approach in the design and implementation of a software solution

P5.1uses and justifies the need for appropriate project management techniques

P5.2uses and develops documentation to communicate software solutions to others

P6.2communicates with appropriate personnel throughout the software development process

P6.3designs and constructs software solutions with appropriate interfaces.

2Assessment Task Description

This assessment task requires you to design, develop, check and document a program in Microsoft Visual Basic. You will follow the Program Development Lifecycle.

Marks will be awarded for work related towards completing each stage of the Development Lifecycle. Details of marks and marking criteria are set out in the Rubric for this assignment.

3Assessment Due Dates

  • The deliverables for this assessment task are to be submitted using the ‘Assignments’ facility in Moodle. They must be supplied by the dates set out in the table below.

Phase / Due
Define & Design / Monday 21st August
Build / Monday 28th August
Check / Monday 4th September
Document
Evaluate

4Program Definition – “The Memory Game”

You need to develop a memory game. Players will test their memory by attempting to correctly type a set of 6 random characters (that is, not real words) that are displayed to them for only a brief amount of time. If the player successfully types the same 6 characters, display an appropriate message indicating to the player they were correct. If the player does not type the matching 6 characters, display an appropriate message. After showing the player their success/failure message, clear the screen ready for another game.

Players can make the game harder by reducing the number of seconds the characters are displayed to them, or easier by increasing the number of seconds the characters are displayed. The default for the game is displaying the set of characters for 10 seconds. Minimum display time is 2 seconds, maximum is 20 seconds.

Players will need to know how to install and operate your game on their computer. Players need access to a help screen that explains how to play your game. Developers will need to know how your game works so they can make any necessary fixes or enhancements.

5Program Features

  • The 6 random characters can be alphabetic, numeric or special characters. An example of six random characters could be “8e3m&7”
  • You can come up with any method you see fit to generate the 6 random characters
  • You must use at least one sub-program and at least one function in your program.
  • Your game should be visually appealing
  • You should aim to design a game that will be intuitive for the user
  • Your code must be documented internally
  • You must include a help screen for the user explaining how to play the game

6What you need to hand in

All work must be submitted electronically. Use the drawing tools in Microsoft Word to create any flowcharts or diagrams for submission.

6.1Define & Design Phase

  1. A description of the program, written in your own words
  2. An IPO (Input, Process, Output) chart analysing the problem
  3. The algorithm that your program will use to check if what the user typed in matched what was displayed to them. This can be done using pseudocode or a flowchart.
  4. The algorithm/s for the steps in your program you will develop as sub-programs
  5. The algorithm/s for the steps in your program you will develop as functions
  6. A list of at least twodata types that will be used in your program, and an explanation of why & how each data type you identify will be used
  7. A screen design for your main screen.
  8. A screen design for your help screen.
  9. A list of what kinds of User Documentation you think should be written for your game, and why.
  10. A list of what kinds of Developer Documentation you think should be written for your game, and why.

6.2Build Phase

  1. A function diagram for your program showing how all the parts will fit together (or if you prefer, a flowchart). This will be part of your Developer Documentation
  2. The name of the sub-program you wrote
  3. The name of the function you wrote
  4. A list of the Softcopy files needed to run your game, written in Visual Basic
  5. A copy of the files needed to run your game (copy onto Moodle)

6.3Check your Program Phase

  1. A test data table, showing test data with expected and actual results.

6.4Documentation Phase

  1. The definition of who your target user audience will be
  2. User instructions on how to install and play your game (in hard or soft copy)
  3. A System Requirements Definition (make this simple so that both users and developers can understand it)
  4. A System Description (this should be more detailed and aimed at the developer)

6.5Evaluation Phase

  1. A list of three things you like about the design or coding of your game and why
  2. A list of three things that you found hard or disliked doing during this assessment task and why
  3. A list of three things that you would change in your code if you had more time and why

7Assessment Task Rubric

The table below sets out the criteria that will be used to mark this assessment task.

Phase / Criteria / MarkRange / Available Mark
Define and Design / Clear, detailed, logical description of the purpose of the program, describes everything the program will do
Complete IPO Chart showing all elements of the solution
Algorithms written are skillful, logical and likely to achieve all requirements of the program
Skillfully substantiated list of three data types
Screen Designs that clearly demonstrate deep consideration of the user (is ergonomically sound, intuitive, uses consistent font and colour, uniform size and placement of command buttons, grouping and alignment of objects)
Expertly identifies the User and Developer Documentation required, provides logical and well substantiated arguments supporting choice of Documentation / High
17-20 / /20
Accurate description of the program, identifies most of what the program will do
Near complete IPO Chart, showing most elements of the solution
Algorithms written likely to achieve most requirements of the program
Acceptably substantiated list of three data types
Screen Designs that demonstrate some consideration of the user (is ergonomically sound, intuitive, uses consistent font and colour, uniform size and placement of command buttons, grouping and alignment of objects)
Acceptably identifies the User and Developer Documentation required, provides some good arguments supporting choice of Documentation / Satisfactory
13-16
Poor description of the program or description that excludes important information
Incomplete IPO Chart, misses many elements of the solution
Algorithms written areclumsy or ineffective, unlikely to achieve requirements of the program
Roughly substantiated list of three data types/three data types not covered
Screen Designs that demonstrate little or no consideration of the user (is ergonomically sound, intuitive, uses consistent font and colour, uniform size and placement of command buttons, grouping and alignment of objects)
Partly identifies the User and Developer Documentation required, provides poor (or no) arguments supporting choice of Documentation / Progressing
0–12
Build / Function Diagram or Pseudocode comprehensively represents everything the program is designed to do
Sub-Program and Function are used, clearly identified, skillfully written, and are well documented
Complete list of Softcopy files provided
Complete copy of all Softcopy files needed to run game
Excellent use of internal documentation (Comments, indentation, whitespace, meaningful variable names)
Program works,cleverly meets the Program Definition / High
30-35 / /35
Function Diagram or Pseudocode clearly attempt to meet program design, achieves most of design
Sub-Program and Function are attempted, clearly identified, acceptably written, and are documented
Complete list of Softcopy files provided
Complete copy of all Softcopy files needed to run game
Good attempt at internal documentation (Comments, indentation, whitespace, meaningful variable names)
Program works and mostly fits the Program Definition / Satisfactory
18-29
Function Diagram or Pseudocode comprehensively represents what the program is designed to do
Sub-Program and Function are not attempted, clearly identified, well written, and are well documented
Incomplete list of Softcopy files provided
Incomplete copy of all Softcopy files needed to run game
Scarce use of internal documentation (Comments, indentation, whitespace, meaningful variable names)
Program works but does not meet Program definition / Progressing
0-17
Check / Comprehensive Test Data Table provided
Expected results in Test Table cover valid and invalid data for all scenarios
All actual results are recorded / High
8-10 / /10
Adequate Test Data Table provided
Expected results in Test Table cover valid and invalid data for some scenarios
Most actual results are recorded / Satisfactory
5-7
Sketchy Test Data Table provided
Expected results in Test Table do not cover both valid and invalid data
Actual results partially or not recorded / Progressing
0-4
Document / Target audience clearly identified
Clear, easy to read user instructions aimed at the target audience
Effectively written and complete System Requirements Definition and System Description / High
20-25 / /25
Target audience clearly identified
User instructions adequately written and meet most of the needs of the target audience
Adequately written, mostly complete System Requirements Definition and System Documentation / Satisfactory
13-20
Target audience partly identified
User instructions ambiguous, meet some of the needs of the target audience
Ineffectively written, partly complete System Requirements Definition and System Documentation / Progressing
0-12
Evaluate / Carefully considered, skillfully substantiated list of things you liked about the design; found hard or disliked; would change with your code if you had time. / High
9-10 / /10
Some consideration, clear effort made in substantiating a list of things you liked about the design; found hard or disliked; would change with your code if you had time. / Satisfactory
6-8
Minimal consideration or partly substantiated list of things you liked about the design; found hard or disliked; would change with your code if you had time. / Progressing
0-5
TOTAL / 100

8Suggested Time Allocation

  • Eight periods of in-class time have been allocated to this assessment task
  • Use the suggested time-frame below, or alternatively increase your amount of in-class development time by completing non-development related activities at home.

Phase / Class Time
Define & Design / 2 Periods
Build / 3 Periods
Check / ½ Period
Document / 2 Periods
Evaluate / ½ Period
TOTAL / 8 Periods

9Resources Available to you

  • Visual Basic help facility
  • PowerPoint references on Moodle (User Interface design, User/Developer Documentation, Modules of code)
  • Word document scaffolds for completing non-programming activities for this assignment. These can be located on Moodle. There is one for the Define & Design Phase, and another encompassing the Check, Document and Evaluate Phases.