Year 11 Assessment Task

Year 11 Assessment Task Software Design and Development – Preliminary Course

Weighting: 10% Issued Date: Monday 14th August 2006 Final Part Due: Monday 4th September 2006 Unit: 8.2 Building Software Solutions

1 Outcomes

A student: P1.2 describes and uses appropriate data types P4.2 investigates a structured approach in the design and implementation of a software solution P5.1 uses and justifies the need for appropriate project management techniques P5.2 uses and develops documentation to communicate software solutions to others P6.2 communicates with appropriate personnel throughout the software development process P6.3 designs and constructs software solutions with appropriate interfaces.

2 Assessment 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.

3 Assessment 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 Document Monday 4th September Evaluate 4 Program 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.

5 Program 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 6 What 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.1 Define & 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 two data 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.2 Build 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.3 Check your Program Phase 1. A test data table, showing test data with expected and actual results.

6.4 Documentation 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.5 Evaluation 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 7 Assessment Task Rubric The table below sets out the criteria that will be used to mark this assessment task.

Phase Criteria Mark Range Available Mark Define and Design Clear, detailed, logical description of the purpose of the program, describes everything the program will do High Complete IPO Chart showing all elements of the solution Algorithms written are skillful, logical and likely to achieve all requirements of the program 17-20 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 Accurate description of the program, identifies most of what the program will do Satisfactory Near complete IPO Chart, showing most elements of the solution Algorithms written likely to achieve most requirements of the program 13-16 Acceptably substantiated list of three data types /20 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 Poor description of the program or description that excludes important information Progressing Incomplete IPO Chart, misses many elements of the solution Algorithms written are clumsy or ineffective, unlikely to achieve requirements of the program 0–12 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 Build Function Diagram or Pseudocode comprehensively represents everything the program is designed to do High Sub-Program and Function are used, clearly identified, skillfully written, and are well documented Complete list of Softcopy files provided 30-35 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 Function Diagram or Pseudocode clearly attempt to meet program design, achieves most of design Satisfactory Sub-Program and Function are attempted, clearly identified, acceptably written, and are documented Complete list of Softcopy files provided 18-29 /35 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 Function Diagram or Pseudocode comprehensively represents what the program is designed to do Progressing Sub-Program and Function are not attempted, clearly identified, well written, and are well documented Incomplete list of Softcopy files provided 0-17 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 Check Comprehensive Test Data Table provided High Expected results in Test Table cover valid and invalid data for all scenarios 8-10 All actual results are recorded Adequate Test Data Table provided Satisfactory Expected results in Test Table cover valid and invalid data for some scenarios 5-7 /10 Most actual results are recorded Sketchy Test Data Table provided Progressing Expected results in Test Table do not cover both valid and invalid data 0-4 Actual results partially or not recorded Document Target audience clearly identified High Clear, easy to read user instructions aimed at the target audience 20-25 Effectively written and complete System Requirements Definition and System Description Target audience clearly identified Satisfactory User instructions adequately written and meet most of the needs of the target audience 13-20 /25 Adequately written, mostly complete System Requirements Definition and System Documentation Target audience partly identified Progressing User instructions ambiguous, meet some of the needs of the target audience 0-12 Ineffectively written, partly complete System Requirements Definition and System Documentation Evaluate Carefully considered, skillfully substantiated list of things you liked about the design; found hard or disliked; would High change with your code if you had time. 9-10 Some consideration, clear effort made in substantiating a list of things you liked about the design; found hard or Satisfactory /10 disliked; would change with your code if you had time. 6-8 Minimal consideration or partly substantiated list of things you liked about the design; found hard or disliked; Progressing would change with your code if you had time. 0-5 TOTAL 100 8 Suggested 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

9 Resources 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.