Sie sind auf Seite 1von 5

Software Engineering Project (COM2027) Final Audit – Software Development

Description

Group Number:

Audit – Software Development Description Group Number: Grade Documentation – SVN logs, design documentation,

Grade

Documentation – SVN logs, design documentation, naming conventions: [20%]

Help
Help

Structure of source code: [15%]

Help
Help

Code comments and technical documentation: [15%]

Help
Help

Prototype:

Project checked out from trunk of the group’s SVN repository compiles in Eclipse without errors (other than build paths): [5%] In addition, the project checked out runs the game in the emulator from Eclipse normally.: [5%]

than build paths): [5%] In addition, the project checked out runs the game in the emulator
than build paths): [5%] In addition, the project checked out runs the game in the emulator
than build paths): [5%] In addition, the project checked out runs the game in the emulator

Scaled Grade (maximum 60%):

from Eclipse normally.: [5%] Scaled Grade (maximum 60%): Briefly justify the overall grade, and give additional

Briefly justify the overall grade, and give additional feedback.

justify the overall grade, and give additional feedback. Instructions The group examiner should complete this

Instructions

The group examiner should complete this assessment. When complete, this is to be submitted on the following folder on SVN:

https://svn-student.eps.surrey.ac.uk/svn/COM2027/2012-2013/Assessment/FinalAudit/

The filename should be audit-final-XX.pdf , where XX is the two-digit group number. Please follow the naming convention strictly as a script will be used to collect grades. The marking criteria should be read in conjunction with the University UG Grade Descriptors. All grades are to be considered provisional until Board of Examiners approval.

Academic Year 2012–2013

Form v.4321

Marking Criteria

Grade

Description

Documentation – SVN logs, design documentation, naming conventions: [20%] 0%–39%: The limited documentation provided is incoherent and/or misrepresents substantial parts of the project. Naming of files misrepresents the naming conventions. 40%–49%: The documentation is maintained at a limited level and reflects a limited understanding of the project with inconsistencies and/or omissions. Limited adherence to naming conventions. 50%–59%: The documentation is maintained and reflects a basic understanding of the project with some inconsistencies and/or omissions. Naming conventions are followed with some short-comings. 60%–69%: The documentation is maintained at a near professional level and reflects a good understand- ing of the project with only some minor inconsistencies and/or omissions. Naming conventions are followed meticulously, perhaps with minor and obvious short-comings. 70%–79%: The complete documentation is maintained at a professional level and reflects a substantive understanding of the project. Naming conventions are followed meticulously. 80%–100%: The complete documentation is maintained excellently at a professional level and reflects an exceptionally substantive understanding of the project. Naming conventions are followed meticulously.

Structure of source code: [15%] 0%–39%: A limited amount of code is provided and the code mainly fails to follow professional object- oriented practice. The lack of clear structure severely impacts readability. Alternatively, too little code has been provided to assess adherence to object-oriented practice, structure and readability. 40%–49%: A limited amount of code is provided and the code follows professional object-oriented practice with considerable shortcomings. The code is only partly structured, affecting readability. 50%–59%: A fair amount of code is provided and the code follows professional object-oriented practice with some shortcomings. The code is only partly structured, but still readable. 60%–69%: An appropriate amount of code is provided and the code follows professional object-oriented practice with a few minor shortcomings. The code is mostly well structured and readable. 70%–79%: An appropriate amount of code is provided and the code follows professional object-oriented practice to an advanced degree. The code is very well structured and readable. 80%–100%: An appropriate amount of code is provided and the code follows professional object-oriented practice to an exceptional degree. The code is excellently structured and readable.

Code comments and technical documentation: [15%] 0%–39%: The code is commented in an incoherent or misleading way. Many comments are lacking or do not contain relevant information. 40%–49%: The code is commented at a limited level with inconsistencies and/or omissions. Comments are not concise and complete. 50%–59%: The code is commented, both using Javadoc and normal comments, however with some inconsistencies and/or omissions. Comments can be improved with respect to relevance, conciseness and completeness. They may have some shortcomings. 60%–69%: The code is commented at a near professional standard, both using Javadoc and normal comments. Comments are mostly relevant, concise and complete, and may have minor short- comings. 70%–79%: The code is commented at good professional standard, both using Javadoc and normal com- ments. Comments are relevant, concise and complete. Javadoc comments are syntactically correct. 80%–100%: The code is commented at an exceptionally professional standard, both using Javadoc and normal comments. Comments are relevant, concise and complete. Javadoc comments are syntactically correct.

Academic Year 2012–2013

Form v.4321

Software Engineering Project (COM2027) User Acceptance Test

Reviewer’s Group Number:

(COM2027) User Acceptance Test Reviewer’s Group Number: Group Reviewed: Description Grade Gameplay: Run the

Group Reviewed:

Acceptance Test Reviewer’s Group Number: Group Reviewed: Description Grade Gameplay: Run the game on the

Description

Grade

Gameplay:

Run the game on the emulator with the Nexus One device definition, with the Android 2.1 (API Level 7) target, the ARM CPU/ABI, and remaining settings at default values. Rate the gameplay according to the following criteria. Gameplay originality (consider presentation/features, as well as concept) 1 : [5%]

presentation/features, as well as concept) 1 : [5%] Fun factor (what makes a game fun is

Fun factor (what makes a game fun is subjective; in general, a game is to be considered fun if it’s addictive, captivating, entertaining, or otherwise enjoyable): [5%]

captivating, entertaining, or otherwise enjoyable): [5%] Graphical presentation (rate the in-game graphics for
captivating, entertaining, or otherwise enjoyable): [5%] Graphical presentation (rate the in-game graphics for
captivating, entertaining, or otherwise enjoyable): [5%] Graphical presentation (rate the in-game graphics for

Graphical presentation (rate the in-game graphics for appropriateness and finish): [5%]

the in-game graphics for appropriateness and finish): [5%] Extra features (rate here any other gameplay elements

Extra features (rate here any other gameplay elements not included above, or not strictly re- quired): [5%]

not included above, or not strictly re- quired): [5%] Playability (i.e. usability of controls): [5%] Intuitiveness
not included above, or not strictly re- quired): [5%] Playability (i.e. usability of controls): [5%] Intuitiveness
not included above, or not strictly re- quired): [5%] Playability (i.e. usability of controls): [5%] Intuitiveness

Playability (i.e. usability of controls): [5%]

quired): [5%] Playability (i.e. usability of controls): [5%] Intuitiveness (in other words, how much of the

Intuitiveness (in other words, how much of the game could you enjoy before reading the online help?): [5%]

game could you enjoy before reading the online help?): [5%] Online help and error messages (how
game could you enjoy before reading the online help?): [5%] Online help and error messages (how
game could you enjoy before reading the online help?): [5%] Online help and error messages (how

Online help and error messages (how well does the provided help function explain the game? Is it available anywhere where it might be needed? Are there helpful error messages to direct the user if the user does something unexpected?): [5%]

the user if the user does something unexpected?): [5%] Responsiveness (i.e. does it react to user
the user if the user does something unexpected?): [5%] Responsiveness (i.e. does it react to user

Responsiveness (i.e. does it react to user inputs? Can the user interrupt/leave the game at any point in time?): [5%]

user interrupt/leave the game at any point in time?): [5%] Difficulty (is the difficulty level appropriate,
user interrupt/leave the game at any point in time?): [5%] Difficulty (is the difficulty level appropriate,

Difficulty (is the difficulty level appropriate, and does it progress well with increasing levels?):

[5%]

and does it progress well with increasing levels?): [5%] (Continued on next page) 1 For example,
and does it progress well with increasing levels?): [5%] (Continued on next page) 1 For example,

(Continued on next page)

1 For example, ‘Battle Chess’ had originality due to its presentation, even though the game of chess was already well-known.

Academic Year 2012–2013

Form v.4393

(Continued from previous page)

Description

Grade

Compatibility:

Run the game on the emulator with the following device definitions and any specific settings, as directed. In each case, rate the overall gameplay (does the game run smoothly? is it still fun to play? does it still react to user input? etc.). 10.1" WXGA (Tablet), Android 4.2 (API Level 17) target: [5%]

WXGA (Tablet) , Android 4.2 (API Level 17) target: [5%] Nexus 7 , Android 4.2 (API

Nexus 7, Android 4.2 (API Level 17) target: [5%]

[5%] Nexus 7 , Android 4.2 (API Level 17) target: [5%] 3.7" WVGA – RAM: 256

3.7" WVGA – RAM: 256 MiB: [5%]

Level 17) target: [5%] 3.7" WVGA – RAM: 256 MiB: [5%] 2.7" QVGA : [5%] 3.2"

2.7" QVGA: [5%]

3.7" WVGA – RAM: 256 MiB: [5%] 2.7" QVGA : [5%] 3.2" HVGA slider (ADP1) :

3.2" HVGA slider (ADP1): [5%]

[5%] 2.7" QVGA : [5%] 3.2" HVGA slider (ADP1) : [5%] Other Requirements: Run the game
[5%] 2.7" QVGA : [5%] 3.2" HVGA slider (ADP1) : [5%] Other Requirements: Run the game
[5%] 2.7" QVGA : [5%] 3.2" HVGA slider (ADP1) : [5%] Other Requirements: Run the game
[5%] 2.7" QVGA : [5%] 3.2" HVGA slider (ADP1) : [5%] Other Requirements: Run the game
[5%] 2.7" QVGA : [5%] 3.2" HVGA slider (ADP1) : [5%] Other Requirements: Run the game
[5%] 2.7" QVGA : [5%] 3.2" HVGA slider (ADP1) : [5%] Other Requirements: Run the game

Other Requirements:

Run the game and test for the following events. Does the game pause when there is an incoming call? Does it resume when the call is finished?:

[5%]

call? Does it resume when the call is finished?: [5%] Is the high score feature implemented?
call? Does it resume when the call is finished?: [5%] Is the high score feature implemented?

Is the high score feature implemented? (that is, if you score sufficiently high, do you get to enter your name in the high score list?) Are high scores (and names) persistent between reboots?:

[5%]

high scores (and names) persistent between reboots?: [5%] This space is for additional feedback. Scaled Grade
high scores (and names) persistent between reboots?: [5%] This space is for additional feedback. Scaled Grade

This space is for additional feedback.

Scaled Grade (maximum 100%):

is for additional feedback. Scaled Grade (maximum 100%): Complete the following with details of your test
is for additional feedback. Scaled Grade (maximum 100%): Complete the following with details of your test

Complete the following with details of your test setup:

Android SDK Version OS (and version) CPU type and speed / GHz RAM (Main) Memory

Android SDK Version OS (and version) CPU type and speed / GHz RAM (Main) Memory Academic
Android SDK Version OS (and version) CPU type and speed / GHz RAM (Main) Memory Academic
Android SDK Version OS (and version) CPU type and speed / GHz RAM (Main) Memory Academic
Android SDK Version OS (and version) CPU type and speed / GHz RAM (Main) Memory Academic

Academic Year 2012–2013

Form v.4393

Instructions

Each group should fill in a separate form for each of the games being reviewed. In each case, rate the game according to the criteria specified using the following five-point scale:

Excellent Surpasses expectations; significantly better than requirements

Very Good Meets all requirements; generally exceeds expected level

Acceptable Generally meets expected level; some deficiencies may exist but none of major concern

Weak Generally fails to meet expected level; significant deficiencies

Poor Significantly below requirements; many deficiencies

Missing Applies only when the given requirement has not been addressed

For each listed criterion write a one-line comment outlining your main reason for your rating. These comments will be returned to the group that wrote the game. Please make them as helpful, informative, precise, and constructive as possible (just like the feedback you would like to receive yourselves). When complete, this is to be submitted on the following folder on SVN:

https://svn-student.eps.surrey.ac.uk/svn/COM2027/2012-2013/Group_XX/documentation/uat/

where XX is your two-digit group number. The filename should be user-acceptance-XX-YY.pdf , where XX is your two-digit group number and YY is the two-digit group number for the group you’re reviewing. Please follow the naming convention strictly as a script will be used to collect grades. Also note that the submitted form should be the one completed with Acrobat, not a scanned copy. This form is only submitted electronically; there is no need to submit a printed copy. This grade will in part determine the raw mark for the group you’re reviewing; the quality of your review will determine the scaling factor to be applied to your group’s grade. All grades are to be considered provisional until Board of Examiners approval.

Academic Year 2012–2013

Form v.4393